Automatically Provide Cargo-related Environment Variables as WiX Variables

[volks73]

As discussed and finally realized by me in #113, the user may want access to various build-related variables within his or her own custom WXS file to create an installer depending on the build environment. For example, determine if the -gnu or -msvc toolchains are used. The Cargo environment variables list should be reviewed and determine which should be included automatically and which can be accessed from a cargo subcommand.

1. I am not sure if any of these variables are accessible from a cargo subcommand and/or the best method of obtaining them.
2. A consistent naming convention for the variable names needs to be established. Rust constant style (CARGO_CONSTANT) or Wix variable style (CargoConstant)? Prefix with Cargo or CargoWix?

[roblabla]

So there isn't any easy way to tell cargo "give me all the variables" (well, I can think of a few hacks, but nothing clean). Here are those we know of today, if they are useful, and if we can get them or not:

• CARGO: Path to cargo binary. Unneeded.
• CARGO_MANIFEST_DIR: cargo-metadata can provide it.
• CARGO_MANIFEST_LINKS: Unnecessary I believe. cargo-metadata can provide it.
• CARGO_FEATURE_<name>: This one's a bit complicated, when combined with cargo wix --no-build, we have no way of knowing which features were used for the build that I know of (though maybe there's some file in the target directory that could tell us? Need to dig.). I do see how it could be useful though.
• CARGO_CFG_<cfg>: Can be acquired with cargo --print cfg. See #126.
• OUT_DIR: Unnecessary, this is build-script specific.
• TARGET: We already pass it. Target triple name.
• HOST: This one's interesting. We technically have it through get_host_triple, but I don't know how useful it would be within a WXS.
• NUM_JOBS: Unneeded.
• OPT_LEVEL, DEBUG: cargo_metadata::Artifact can give it, but that interacts poorly with --no-build.
• PROFILE: We already have it.
• DEP_<name>_<key>: Unneeded.
• RUSTC, RUSTDOC, RUSTC_LINKER: Path to binaries. Unneeded..

[volks73]

• CARGO_CFG_<cfg>: Can be acquired with cargo --print cfg. See #126.

Just a minor correction in case someone finds this issue. It is the rustc --print cfg, not cargo --print cfg. Cargo does not have a --print option.

[volks73]

In summary, the only Cargo variable of interest is the CARGO_FEATURE_<name> variables, but this will take some work to investigation and work and the CARGO_CFG_<cfg> variable, which is available with the rustc --print cfg/rustc-cfg crate. The rest of the variables are either not needed or already provided via other mechanisms.

Since the CARGO_CFG_<cfg> variables are obtained from the rustc --print cfg output, I am going to create another issue (#132) to track and discuss adding rustc --print cfg output as WiX variables and keep this one focused on the Cargo-related variables (now just implementing the CARGO_FEATURE_<name> variables).

[plule]

Hello,

OUT_DIR: Unnecessary, this is build-script specific.

I think this one would actually be very useful for intermediary files generated by build.rs. In my case I have an .svg icon that is converted into a .ico as part of the build process. The recommendation for build scripts is to only produce files in OUT_DIR, so using it in wix with a <Icon Id='icon.exe' SourceFile='$(var.CargoOutDir)\icon.ico'/> would make a lot of sense.

[roblabla]

The problem is, the OUT_DIR is different for each artifact (ergo each binary of a crate has its own OUT_DIR), so if we do this, at the very least it'd be something like CargoOutDirBin<BinName>.