feature request: CARGO_TARGET_DIR_PREFIX

[asomers]

If the CARGO_TARGET_DIR environment variable is set, then cargo will use that as the target directory. However, that variable can't be shared between different workspaces. Thus, anybody who wants to use it must modify his environment every time he switches workspaces.

It would be better for Cargo to support a CARGO_TARGET_DIR_PREFIX variable that is used to calculate the full target directory and can be shared between all workspaces. I propose doing this exactly like FreeBSD's ports tree uses the WRKDIRPREFIX variable:

• If neither CARGO_TARGET_DIR nor CARGO_TARGET_DIR_PREFIX is set, then Cargo will use ${PWD}/target as the target directory.
• If CARGO_TARGET_DIR_PREFIX is set but CARGO_TARGET_DIR isn't, then Cargo will use ${CARGO_TARGET_DIR_PREFIX}/${PWD}/target as the target directory. If it doesn't exist, then Cargo will create it, along with any missing parent directories.
• If CARGO_TARGET_DIR is set, regardless of whether CARGO_TARGET_DIR_PREFIX is, then Cargo will use that for the target directory.

For example:

rustacean@server:~/src/rust/foo$ sudo mkdir /cargo
rustacean@server:~/src/rust/foo$ sudo chmod 1777 /cargo
rustacean@server:~/src/rust/foo$ export CARGO_TARGET_DIR_PREFIX=/cargo
rustacean@server:~/src/rust/foo$ cargo build
...
rustacean@server:~/src/rust/foo$ ls /cargo/home/rustacean/src/rust/foo/target
debug
rustacean@server:~/src/rust/foo$ cd ../bar
rustacean@server:~/src/rust/bar$ cargo build
...
rustacean@server:~/src/rust/bar$ ls /cargo/home/rustacean/src/rust/bar/target
debug

This feature will facilitate the following uses for developers with multiple workspaces:

• Sharing source code amongst multiple machines with different OSes or architectures, which each need their own target directories.
• Sharing source code via NFS for convenience or backup purposes, but building on local filesystems for speed (storing sources on NFS is plenty fast, but storing objects on NFS is very slow).
• Saving storage space by using RAID protection only for source, not objects
• Building from read-only source directories
• Building and testing from noexec source filesystems

[d-e-s-o]

+1 for this feature request. I just noticed how huge the target/ directory can become, seemingly even more so with recent advances in incremental build support (although I haven't compared to the bad old days).

It's a big deal for me for the backup process mentioned above but there is probably one more argument in favor of having something along the lines of CARGO_TARGET_DIR_PREFIX (that I can't see how to implement properly with CARGO_TARGET_DIR) and that is:

• Reducing unnecessary write cycles on an SSD. All target/ data can easily go to a ramdisk backed directory.

[d-e-s-o]

I started working on this feature, mostly for my own benefit. But in case someone is interested:
For 0.27: d-e-s-o@05d4f25
For HEAD: d-e-s-o@4ad0efa

I can bring this issue to conclusion if there is interest (and some guidance with respect to Windows support). But that probably needs some discussion first, given the proposal state the feature is in (and I am unsure about the exact procedure to go through, as I am new to the project; so that would require some hand holding :D)

[d-e-s-o]

I can bring this issue to conclusion if there is interest (and some guidance with respect to Windows support). But that probably needs some discussion first, given the proposal state the feature is in (and I am unsure about the exact procedure to go through, as I am new to the project; so that would require some hand holding :D)

Any comments?

[asomers]

I'm still very interested in this feature. I can't help with Windows, though. But would you like me to test your branch with my setup?

[d-e-s-o]

I'm still very interested in this feature. I can't help with Windows, though. But would you like me to test your branch with my setup?

Sure! More exposure can't hurt.

I am mostly looking for some statement from the Cargo team though, @alexcrichton . Should I just create a pull request and everything is discussed there? I suppose a lagging Windows version will be a problem, so some sort of clarification on that front would be useful.

[asomers]

It works for me. Thanks @d-e-s-o ! My use case is storing source on NFS so I can share it amongst machines of different OSes.

[qmx]

@alexcrichton does this feature needs a RFC/e-RFC to be accepted? That would be immensely useful to me :)

[alexcrichton]

Yes I suspect this will need at least some discussion beyond what's in this issue before landing, perhaps through an RFC.

[qmx]

can you direct me to the proper avenue for discussing this before I sink time into a RFC document?

internals? zulip? discord?

[d-e-s-o]

One conceptual issue I encountered through continued usage is the following: its now possible that multiple users set CARGO_TARGET_DIR_PREFIX, each potentially setting it to the same directory.
I do that for root and my local user user. Let's assume CARGO_TARGET_DIR_PREFIX is /tmp/rust, but that only /tmp exists (not /tmp/rust). Now if I build a project from user first, that may create /tmp/rust/home/user/.... Note here that /tmp/rust is created with user as the owner. Because root (typically) has write access in user created directories everything is fine when root now builds a project whose artifacts reside in, say, /tmp/rust/root/....
But once we swap the order and root builds first, /tmp/rust will be owned by root and user is not able to create /tmp/rust/home in it. While that is expected and logical, it's not a great user experience, I'd argue. I guess we could create directories as world writable? But it seems icky. Haven't found a good solution yet. Perhaps the solution is just to document that behavior, but I see that as last resort.

[qmx]

I think the main thing is not necessarily going with this specific solution, but actually document the problem and try to gather possible solutions.

[asomers]

One conceptual issue I encountered through continued usage is the following: its now possible that multiple users set CARGO_TARGET_DIR_PREFIX, each potentially setting it to the same directory.
I do that for root and my local user user. Let's assume CARGO_TARGET_DIR_PREFIX is /tmp/rust, but that only /tmp exists (not /tmp/rust). Now if I build a project from user first, that may create /tmp/rust/home/user/.... Note here that /tmp/rust is created with user as the owner. Because root (typically) has write access in user created directories everything is fine when root now builds a project whose artifacts reside in, say, /tmp/rust/root/....
But once we swap the order and root builds first, /tmp/rust will be owned by root and user is not able to create /tmp/rust/home in it. While that is expected and logical, it's not a great user experience, I'd argue. I guess we could create directories as world writable? But it seems icky. Haven't found a good solution yet. Perhaps the solution is just to document that behavior, but I see that as last resort.

Yes, @d-e-s-o that's a probably. The best solution is to set the sticky bit on the prefix directory. So the first time you created it, chmod 1777 /tmp/rust. Now, both root and user can happily create subdirectories.

[alexcrichton]

@qmx I suspect internals would probably be best

[epage]

See also #11156

[epage]

Closing in favor of #11156 as that has more discussion. While the title is slightly different, the discussion goes more broad.