passing -o to |cargo rustc| results in rebuilds even when nothing has changed

[froydnj]

This issue is sort of related to #2559, but distinct from it, I think. Consider the following sequence, where we attempt to pass -o to rustc:

# Build a staticlib.
$ env CARGO_TARGET_DIR=. RUSTC=/usr/local/bin/rustc /usr/local/bin/cargo rustc --release --manifest-path /home/froydnj/src/gecko-dev.git/toolkit/library/rust/Cargo.toml --target=x86_64-unknown-linux-gnu --verbose -- -o librul.a
       Fresh mp4parse v0.4.0 (file:///home/froydnj/src/gecko-dev.git/toolkit/library/rust)
   Compiling rul v0.1.0 (file:///home/froydnj/src/gecko-dev.git/toolkit/library/rust)
[...rustc command...]
warning: ignoring specified output filename because multiple outputs were requested
warning: ignoring --out-dir flag due to -o flag.
[...other output elided...]

# Display the mtime of the output file, ${SECONDS}.${NANOSECONDS} form.
$ ls -l --time-style=+%s.%N librul.a
-rw-r--r-- 1 froydnj froydnj 2188818 1469755107.467728813 librul.a

# Rebuild without changing anything.
$ env CARGO_TARGET_DIR=. RUSTC=/usr/local/bin/rustc /usr/local/bin/cargo rustc --release --manifest-path /home/froydnj/src/gecko-dev.git/toolkit/library/rust/Cargo.toml --target=x86_64-unknown-linux-gnu --verbose -- -o librul.a
       Fresh mp4parse v0.4.0 (file:///home/froydnj/src/gecko-dev.git/toolkit/library/rust)
   Compiling rul v0.1.0 (file:///home/froydnj/src/gecko-dev.git/toolkit/library/rust)
[...rustc command...]
warning: ignoring specified output filename because multiple outputs were requested
warning: ignoring --out-dir flag due to -o flag.
[...other output elided...]

# Display the mtime of the output file, which has changed.
$ ls -l --time-style=+%s.%N librul.a
-rw-r--r-- 1 froydnj froydnj 2188818 1469755118.563728993 librul.a

Compare to not passing -o:

$ env CARGO_TARGET_DIR=. RUSTC=/usr/local/bin/rustc /usr/local/bin/cargo rustc --release --manifest-path /home/froydnj/src/gecko-dev.git/toolkit/library/rust/Cargo.toml --target=x86_64-unknown-linux-gnu --verbose
       Fresh mp4parse v0.4.0 (file:///home/froydnj/src/gecko-dev.git/toolkit/library/rust)
   Compiling rul v0.1.0 (file:///home/froydnj/src/gecko-dev.git/toolkit/library/rust)
[...other output elided...]
$ env CARGO_TARGET_DIR=. RUSTC=/usr/local/bin/rustc /usr/local/bin/cargo rustc --release --manifest-path /home/froydnj/src/gecko-dev.git/toolkit/library/rust/Cargo.toml --target=x86_64-unknown-linux-gnu --verbose
       Fresh mp4parse v0.4.0 (file:///home/froydnj/src/gecko-dev.git/toolkit/library/rust)
       Fresh rul v0.1.0 (file:///home/froydnj/src/gecko-dev.git/toolkit/library/rust)

I would expect these two sequences to do a build the first time and then nothing the second time.

[alexcrichton]

I believe this is because Cargo knows the output of the compiler, and if it doesn't find it in the expected place it assumes the compiler didn't run to begin with. In that sense, this is expected behavior I think.

Could you clarify what you're using cargo rustc for, though?

[froydnj]

I believe this is because Cargo knows the output of the compiler, and if it doesn't find it in the expected place it assumes the compiler didn't run to begin with. In that sense, this is expected behavior I think.

This is expected behavior generally, or this is expected behavior given that cargo rustc doesn't notice the -o flag being passed?

Could you clarify what you're using cargo rustc for, though?

I'm using cargo rustc so I can control where the compiler output goes. It's easier to integrate cargo into third-party build systems if you can make cargo's idea of where output goes conform to the wider world, instead of the reverse.

[alexcrichton]

Ah yeah to clarify this is expected behavior of cargo rustc. Cargo doesn't parse the options you pass it (intended for the compiler) and try to operate over those, it's currently intended that cargo rustc is a debugging tool, not a 100% robust build tool.

I'm using cargo rustc so I can control where the compiler output goes.

Out of curiosity, can this be done with CARGO_TARGET_DIR and then plucking it out of there?

[froydnj]

Out of curiosity, can this be done with CARGO_TARGET_DIR and then plucking it out of there?

CARGO_TARGET_DIR just changes where the $target/$build_kind directories are created, so the problem is the same regardless of whether CARGO_TARGET_DIR is specified.

I mean, you /can/ pluck things out of cargo's directory structure, it is just less convenient to do so (especially since the directory structure changes depending on what kind of build you're doing).

[alexcrichton]

True yeah, although the only change in directory structure should be "debug" vs "release". Cargo also produces multiple outputs, so a general "place the output file here" may not work so well :(

[carols10cents]

I mean, you /can/ pluck things out of cargo's directory structure, it is just less convenient to do so (especially since the directory structure changes depending on what kind of build you're doing).

True yeah, although the only change in directory structure should be "debug" vs "release".

I believe this aspect is the best we can do, either using CARGO_TARGET_DIR or the target directory listed by cargo metadata.

I'm using cargo rustc so I can control where the compiler output goes. It's easier to integrate cargo into third-party build systems if you can make cargo's idea of where output goes conform to the wider world, instead of the reverse.

I believe this request is a duplicate of #4427.

Once cargo knows where its output directory is (once we actually enable setting it), the original issue noted in the description should be solved.

If I'm misunderstanding or missing something, please reopen! Thank you!