Target configuration for binaries

[MichaelMcDonnell]

I would like to be able to specify different main files depending on the operating system. I ran into this problem in Servo where there are two main files. The main.rs file is for Android and includes the main2.rs file for the desktop using the include macro:

#[cfg(not(target_os = "android"))]
include!("main2.rs");

#[cfg(target_os = "android")]
pub fn main() {
    println!(
        "Cannot start /ports/servo/ on Android. \
         Use /support/android/apk/ + /ports/libsimpleservo/ instead"
    );
}

Using the include macro is not great because it breaks my IDE. I am not able to easily jump to the code. I also suspect using macros adds a small compile time overhead.

It could be solved using cfg_if crate (see my Servo cfg_if-main branch), and the code is not that nested, but it could be simpler with cargo support.

Another use case could be something like BusyBox but where certain system binaries are only needed on specific platforms. For example, something that queries Linux settings would only be compiled for Linux.

The Cargo.toml file shows how I would like the feature to work:

[package]
name = "target-cfg-bin-example"
version = "0.2.0"
authors = ["Michael Mc Donnell <michael@mcdonnell.dk>"]
edition = "2018"
autobins = false

# Use the standard `main.rs` for all operating systems except Android.
[[bin]]
name = "target-cfg-bin-example"
path = "src/main.rs"
target = "cfg(not(android))"

# Use the `main_android.rs` main file on Android
[[bin]]
name = "target-cfg-bin-example"
path = "src/main_android.rs"
target = "cfg(android)"

[dependencies]

It currently results in the following error message:

error: failed to parse manifest at `/home/michael/src/target-cfg-bin-example/Cargo.toml`

Caused by:
  found duplicate binary name target-cfg-bin-example, but all binary targets must have a unique name

You can clone the example from https://github.com/MichaelMcDonnell/target-cfg-bin-example

UPDATE 1: I changed the Cargo.toml proposal to add a target key/value pair on the binary definition instead of using the target array. Thanks to @ehuss for the suggestions. It became apparent to me too when I tried to implement it. For dependencies the target has to be applied to each dependency key/value pair so it make sense it is defined for the table/array that has them. For binaries it needs to be applied to the table but not to each key/value pair, so having it as a key/value pair makes sense.

UPDATE 2: I tried getting rid of the include macro using the cfg_if crate (see my Servo cfg_if-main branch), and the code is not that nested, but it could be simpler with cargo support. I've updated issue description with this information.

See also

• Allow specifying a set of supported target platforms in Cargo.toml #6179 for specifying supported platform targets for a package
• Support [target.'cfg(...)'.lib] sections #12260 for specifying build target configuration per platform

[ehuss]

I think the usual solution here is to place the cfg expressions in main.rs. For example:

cfg_if! {
    if #[cfg(target_os = "android")] {
        mod impl_android;
        use impl_android::*;
    } else {
        mod impl_default;
        use impl_default::*;
    }
}

Or some variant of that. I'm not sure I follow the comment about using include_bytes, maybe you could explain that more or show an example?

I would maybe lean more towards having some kind of requirements specification for the binary definition instead of using something like the [[target]] array. Cargo targets already have required-features, so maybe something more extensible could help. I thought there was already an issue or RFC about this, but I can't find it.

Also, unfortunately the word target is overloaded and means two completely different things in this context.

[MichaelMcDonnell]

Thanks for the help @ehuss! I've updated the issue description. I will try to create an example to show what using the cfg_if macro in Servo would look like. I'm also working on the implementation itself.

I also tried searching for an existing issue but didn't find any. Do you know of anybody who might know how to find the issue or RFC?

[ithinuel]

Hi, I was looking for a solution to that with a slightly different use case.

Building a library targetting embedded devices. An example demonstrates the features using linux-embedded-hal. This example cannot build for windows or macos so cfg_if the whole example to have an empty main as an alternative doesn't seem great.

I was hoping that I could "disable" the example using something along:

[[example]]
name = "demo"
required-features = ["use_std"]
target = 'cfg(target_os = "linux")'

Although If I ever come to add support for windows or mac, I don't necessarily need the name to be the same.

[epage]

btw there is #6179 for doing this on the package level

Like my proposal there, I'd suggest we call the field required-target to mirror required-features to suggest that it is required and this build-target should be skipped if it isn't present

[mqudsi]

I think this should be possible without anything in Cargo.toml (so no package-level management) in order to handle auto-discovered code like examples without introducing an undue burden.

A lot of no_std-compatible packages without default = [ "std" ] or crates with various optional features and samples under examples/ that demonstrate their use if compiled with --features foo will fail a bare cargo test when it autodiscovers and tries to compile all the code under examples/.

The naïve approach I think most developers would reach for in this case is to just put #![cfg(feature = "foo")] at the top of examples/foo.rs, but then cargo test fails with

consider adding a main function to examples/foo.rs

There isn't a simple solution for this error. If you try to include #[cfg(not(feature = "foo"))] fn main() { panic!("Requisite feature not enabled!") } after, it won't be seen because of the preceding #![cfg(...)]. If you try placing it before, the #![cfg(...)] will break because that needs to come before anything else (other than comments and whitespace). You have to annotate everything in the file (functions, each line of import, etc) separately with #[cfg(feature = "foo")] and provide the fallback #[cfg(not(feature = "foo"))] fn main() { ... } to work around this issue.

If there were some way for a bare cargo test (not specifying a particular target) to detect this specific error and swallow it, that would be the most "natural" solution. But I know that this would represent somewhat of an inversion of control since cargo should not (generally) be in the business of doing anything with rustc errors..