Ability to conditionally compile from a workspace

[Firstyear]

Hi there,

We have recently been having an issue where we can't easily select components for compilation from a workspace based on target_family. We have a generic server binary that can run on all platforms, and two platform/target specific tools for unix vs windows.

What we would like is a way to say:

[workspace]

members = [
    "generic_server"
]

[workspace.cfg(target_family = "unix")]
members += [
    "unix tool"
]

[workspace.cfg(target_family = "windows")]
members += [
    "windows tool"
]

However, we can't find a way to do this effectively, and even within the tools, we can't do target conditional compilation for libs or bins. This means we are left trying to do cfg based on target family inside the libs and binaries instead which feels a bit messy to us. The alternate is to "de-workspace" our project, but then we lose valuable maintenance features like workspace specified dependencies.

I think it would be a significant improvement for rust/cargo to support such conditional compilation rules in workspaces.

[weihanglo]

Looks like a duplicate of #5220? Also somehow related to #11526.

[weihanglo]

In the meanwhile, you can use empty fn main() or empty lib.rs with #[cfg(…)] to avoid the actual compilation.

[yaleman]

Definitely looks like #5220 might apply 😄

or empty lib.rs with #[cfg(…)]

Could you expand on this a little? Is it possible to specify an alternate source path on libs per-target?

[weihanglo]

Take home crate as an example. Just create a file and add a use statement with a cfg above.

cargo/crates/home/src/lib.rs

Lines 68 to 75 in 0c33172

	#[cfg(windows)]
	use windows::home_dir_inner;
	#[cfg(any(unix, target_os = "redox"))]
	fn home_dir_inner() -> Option<PathBuf> {
	#[allow(deprecated)]
	std::env::home_dir()
	}

In general, you could have several Rust source files. Import them respectively with corresponding cfg, such as

src/
├── lib.rs
├── this_is_not_windows.rs
└── windows.rs

And the code may look like this:

// lib.rs
#[cfg(windows)] 
use windows::my_function; 
  
#[cfg(not(windows))] 
use this_is_not_windows::my_function; 

[weihanglo]

Going to close this as it is a duplicate of #5220. Let us know if it is wrong. Thank you!

[Firstyear]

Take home crate as an example. Just create a file and add a use statement with a cfg above.

cargo/crates/home/src/lib.rs

Lines 68 to 75 in 0c33172

	#[cfg(windows)]
	use windows::home_dir_inner;
	#[cfg(any(unix, target_os = "redox"))]
	fn home_dir_inner() -> Option<PathBuf> {
	#[allow(deprecated)]
	std::env::home_dir()
	}

In general, you could have several Rust source files. Import them respectively with corresponding cfg, such as

src/
├── lib.rs
├── this_is_not_windows.rs
└── windows.rs

And the code may look like this:

// lib.rs
#[cfg(windows)] 
use windows::my_function; 
  
#[cfg(not(windows))] 
use this_is_not_windows::my_function; 

We can't do that because Windows doesn't have PAM or Nsswitch or equivalents. So on Windows we'd be compiling empty DLL's for no reason.

We'd rather see a way to cfg target platforms at the workspace level so we don't even consider the pam/nsswitch modules at all on windows. And vice versa, we don't want the windows specific code considered when we are on unix.

So I think while the "lib.rs" hack with cfg works, it's a thin cover up of the real problem which is the ability to have workspace members targeted based on platform.