Set the CARGO_BIN_NAME environment variable also when building (binary) examples

[t-rapp]

Problem

The CARGO_BIN_NAME environment variable is useful when building command-line programs (see #8251). It lets the command know its binary name for printing out simple usage instructions.

Currently CARGO_BIN_NAME is only set when building a [[bin]] target, though. In my projects a lot of the examples are wrappers around functions of a library crate to allow testing with custom data, similar to small command-line programs. In those example binaries CARGO_BIN_NAME is not available during compilation.

Proposed Solution

It would be useful to also set the CARGO_BIN_NAME environment variable for (binary) examples.

Notes

No response

[weihanglo]

I think it should be feasible to make it happen here.

 fn fill_rustc_tool_env(mut cmd: ProcessBuilder, unit: &Unit) -> ProcessBuilder {
-    if unit.target.is_bin() {
+    if unit.target.is_executable() {

[weihanglo]

Let's do a quick poll whether to accept this feature: “Set the CARGO_BIN_NAME environment variable also when building (binary) examples”. I don't have any concern so far.

@rfcbot poll T-cargo "feature accept?"

[rfcbot]

Team member @weihanglo has asked teams: T-cargo, for consensus on:

"feature accept?"

• @Eh2406
• @Muscraft
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

[t-rapp]

@weihanglo: This was the line change that I stumbled over, too. From a quick check with a custom-built cargo it works.
Do you intend to write a PR in case the feature gets accepted? Otherwise I can do it.

[weihanglo]

Go ahead when it gets accepted! Also recommend adding some tests and updating docs if needed.

[JRAndreassen]

Hi...

I have an issue that is related to this..

I need to know when the build target is a bin.
Scenario:
I have several sub-projects with their own build script.

• app
  • -build.rs
• libs
  • lib1
    • build.rs
  • lib2
    • build.rs
      One of the build steps is generating a resource file(crate winres).
      When app gets built, the build scripts for lib1 & lib2 runs and creates resource files.
      Which creates duplicates and link fails.

So, I need to find a way to determine if the build is a lib/rlib/exe so I can do something like :

#[cfg(windows)]
pub fn build_resource () {

   #[cfg(bin)]
    if Ok("release".to_owned()) == std::env::var("PROFILE")  {
        let mut res = winres::WindowsResource::new();
        res.set_icon("../libs/myicon.ico")
            ;
        if let Err(e) = res.compile() {
            eprintln!("{}", e);
            std::process::exit(1);
        } 
    }
}

Here is the error I get:

          CVTRES : fatal error CVT1100: duplicate resource.  type:VERSION, name:1, language:0x0409
          LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

Or is that possible some other way ?

Thanks
JR

[weihanglo]

Hi @JRAndreassen. This feels like a separate issue to me, and probably more like a user issue. I don't clearly understand the problem, but you may want to move resource generation to build.rs of app. Unfortunately we are not able to support you here. I'd suggest you try one of the user forums such as https://users.rust-lang.org/ to see if someone can help.

Alternatively, you can also create a new issue explaining the expectation with a reproducer and possible solutions and workarounds. Thank you.

[JRAndreassen]

Hi @weihanglo,

Well, it may be... But it seems like the same issue to me...

The goal is to be able to detect build target type at compile-time.
Specifically in the Build script (build.rs).

My cargo config has these entries:

[lib]
name = "velocloud_sensor"
path = "src/lib.rs"

[lib]
crate-type = ["cdylib"]
name = "velocloud_sensor"
path = "src/lib.rs"

[[bin]]
name = "prtgc_velocloud"
path = "src/main.rs"
build = "build.rs"

In order to determine if I need to build resources for the target,
I need to be able to detect if it is building the bin/lib/rlib/etc..

Such that:

#[cfg(windows)]
pub fn build_resource () {

   #[cfg(bin or cdylib))]
    if Ok("release".to_owned()) == std::env::var("PROFILE")  {
        // Build resources only when the target is an Windows DLL or EXE
        let mut res = winres::WindowsResource::new();
        res.set_icon("../libs/myicon.ico")
            ;
        if let Err(e) = res.compile() {
            eprintln!("{}", e);
            std::process::exit(1);
        } 
    }
   #[cfg(cdylib)]
   {  // build other things for a library
   }
   #[cfg(rlib)]
   {  // build other things for a rlibrary
   }
}

Thanks
JR

[weihanglo]

@t-rapp, since the majority of the Cargo team voted for accepting this, we can move forward implementing this. Thank you!

[alshdavid]

I would also like to have a CARGO_CYDLIB_NAME and TARGET_DIR at build time and integration test time. This will help me consume dynamic libraries in integration tests and rename the files as needed (in the case of Nodejs "addons", from {prefix}name.{ext} to name.node.

[epage]

For target-dir for build.rs, see #9661 (some issues will overlap)

For accessing artifacts in tests, we'd instead want something like how we expose bin paths.

[epage]

Hadn't noticed this is a closed issue. If there isn't an open issue for that need, I'd recommend creating one