Overriding Targets with Periods in the Target Name via Environment Variables

[Alexhuszagh]

I was attempting to override the C++ compiler for thumbv8m.base-none-eabi, however, it looks like cc-rs searches for CXX_thumbv8m.base_none_eabi, which is not a valid identifier (at least for a UNIX shell). The output is:

  TARGET = Some("thumbv8m.base-none-eabi")
  OPT_LEVEL = Some("0")
  HOST = Some("x86_64-unknown-linux-gnu")
  cargo:rerun-if-env-changed=CXX_thumbv8m.base-none-eabi
  CXX_thumbv8m.base-none-eabi = None
  cargo:rerun-if-env-changed=CXX_thumbv8m.base_none_eabi
  CXX_thumbv8m.base_none_eabi = None
  cargo:rerun-if-env-changed=TARGET_CXX
  TARGET_CXX = None
  cargo:rerun-if-env-changed=CXX
  CXX = None
  RUSTC_LINKER = None
  cargo:rerun-if-env-changed=CROSS_COMPILE
  CROSS_COMPILE = None
  cargo:rerun-if-env-changed=CXXFLAGS_thumbv8m.base-none-eabi
  CXXFLAGS_thumbv8m.base-none-eabi = None
  cargo:rerun-if-env-changed=CXXFLAGS_thumbv8m.base_none_eabi
  CXXFLAGS_thumbv8m.base_none_eabi = None
  cargo:rerun-if-env-changed=TARGET_CXXFLAGS
  TARGET_CXXFLAGS = None
  cargo:rerun-if-env-changed=CXXFLAGS
  CXXFLAGS = None
  cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("true")
  CARGO_CFG_TARGET_FEATURE = None

Specifically, this part failed:

  cargo:rerun-if-env-changed=CXX_thumbv8m.base_none_eabi
  CXX_thumbv8m.base_none_eabi = None

I was wondering if there was a workaround? Worst comes to worst, I can always symlink my toolchain or rename it to arm-none-eabi-g++, but it would be nice to be able to provide envvar overrides.

[Alexhuszagh]

It looks like this could probably be supported if the following lines also had a replacement for '.', such as:

-        let target_u = target.replace("-", "_");
+        let target_u = target.replace("-", "_").replace(".", "_");

I'm not sure how cargo does this, however, and we'd probably want consistency. If changing . to _ is satisfactory, I'd be more than happy to submit a PR.

EDIT: It looks like cargo probably doesn't support this either: https://github.com/rust-lang/cargo/blob/df56877805e613969da837e1ede28fda3a17481d/src/cargo/util/config/key.rs#L48-L58

[dot-asm]

You surely refer to the fact that Bourne shell won't let you set an environment variable with dot in its name. Which formally isn't an indication that cc-rs would fail to read it :-) In fact it's perfectly capable of reading it and acting accordingly. You can use env(1) to set arbitrarily-named variables on a per-command-invocation basis, e.g. env A.B.C=a-b-c cargo ..., to convince yourself that it's the case. So one can't really say that cc-rs fails to fulfill its end of the contract, only that it's inconvenient to use.

[Alexhuszagh]

That's why I qualified "at least for a UNIX shell". because sure, I could use env (although I can't use declare, which is difficult as well), or I could spin up a Python instance and run it as a subcommand, but neither is exactly a great way to provide these overrides. Technically we can also use - in identifiers, but we substitute them for the much easier ergonomics.

[dot-asm]

All I'm saying is that formally you couldn't put it as "Specifically, this part failed:" in the original post :-) But of course one can legitimately make a case for a better user experience.

Just in case, I'm just a cc-rs user, so it's not me you have to make the case for. I responded mostly to "is there a workaround?" :-)