Make asm-targets independent from target name.

[reitermarkus]

We have a custom target definition which is named differently to what the arm-targets crate expects.

I found that the same features can be detected using CARGO_CFG_TARGET_* variables, e.g.:

CARGO_CFG_TARGET_ABI=eabihf
CARGO_CFG_TARGET_ARCH=arm
CARGO_CFG_TARGET_ENDIAN=little
CARGO_CFG_TARGET_ENV=
CARGO_CFG_TARGET_FEATURE=aclass,d32,dsp,fpregs,neon,thumb2,v5te,v6,v6k,v6t2,v7,vfp2,vfp3
CARGO_CFG_TARGET_HAS_ATOMIC=16,32,8,ptr
CARGO_CFG_TARGET_HAS_ATOMIC_EQUAL_ALIGNMENT=16,32,8,ptr
CARGO_CFG_TARGET_HAS_ATOMIC_LOAD_STORE=16,32,8,ptr
CARGO_CFG_TARGET_OS=none
CARGO_CFG_TARGET_POINTER_WIDTH=32
CARGO_CFG_TARGET_VENDOR=unknown

[jonathanpallant]

Are those variables set by cargo, or did you invent them?

Good idea either way. No one loves string parsing targets.

[jonathanpallant]

Ah I see cargo sets them. But because features are not stable, CARGO_CFG_FEATURE is empty, so I cannot see any way to know which Arm architecture I am building for.

Are you using nightly?

[reitermarkus]

Ah, yes, I am using nightly. Seems like CARGO_CFG_TARGET_FEATURE is only set on nightly.

Then again, custom targets also only work on nightly, right?

[jonathanpallant]

Becase the CARGET_TARGET_CFG_FEATURES variable is empty on stable Rust, with this PR the Thumb targets will be mis-detected at Arm targets.

Maybe the code could default to looking at the target string first, and only fall back to CARGO_TARGET_CFG_xxx if that fails?

[jonathanpallant]

Alternative idea:

Use ARM_TARGET_OVERRIDE=aarch64-unknown-none to make arm-targets process the string aarch64-unknown-none instead of $(TARGET)? Then as long as your custom target looks enough like a built-in target, the user can set a variable and all the dependencies's build scripts will work correctly, regardless of using nightly or stable.

[reitermarkus]

Becase the CARGET_TARGET_CFG_FEATURES variable is empty on stable Rust, with this PR the Thumb targets will be mis-detected at Arm targets.

That shouldn't be the case since Arch::from_cargo_env early-returns None if CARGO_CFG_TARGET_FEATURE is unset.

[jonathanpallant]

It's still set, it's just missing all the useful info.

$ cat build.rs
fn main() {
    eprintln!("FEATURES = {:?}", std::env::var("CARGO_CFG_TARGET_FEATURE"));
}
$ cargo build && rg FEATURE ./target --no-ignore
   Compiling testapp v0.1.0 (/Users/jonathan/testapp)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.27s
./target/debug/build/testapp-71c68bd226f9aac7/stderr
1:FEATURES = Ok("aes,crc,dit,dotprod,dpb,dpb2,fcma,fhm,flagm,fp16,frintts,jsconv,lor,lse,neon,paca,pacg,pan,pmuv3,ras,rcpc,rcpc2,rdm,sb,sha2,sha3,ssbs,vh")
$ cargo clean && cargo +nightly build && rg FEATURE ./target --no-ignore
     Removed 59 files, 2.3MiB total
   Compiling testapp v0.1.0 (/Users/jonathan/testapp)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.68s
./target/debug/build/testapp-fce034d1b64435a6/stderr
1:FEATURES = Ok("aes,crc,dit,dotprod,dpb,dpb2,fcma,fhm,flagm,flagm2,fp16,frintts,jsconv,lor,lse,lse2,neon,paca,pacg,pan,pmuv3,ras,rcpc,rcpc2,rdm,sb,sha2,sha3,ssbs,v8.1a,v8.2a,v8.3a,v8.4a,vh")

[reitermarkus]

I see, for target I was using to test this (armv8r-none-eabihf), it is completely unset on stable, hence the confusion.

[jonathanpallant]

There's a reason I resorted to just parsing the target strings 😢

[reitermarkus]

Okay, I now switched the order so that TARGET is used by default and CARGO_CFG_TARGET_* is used as a fallback.

[jonathanpallant]

Ok, looks ok to me. Would love to know more about your JSON target though!

[reitermarkus]

The basis for our targets are these

• https://git.m-labs.hk/M-Labs/artiq-zynq/src/commit/27513e44ac155bbbe819c63c99727a32fcde8ad1/src/armv7-none-eabihf.json
• https://git.m-labs.hk/M-Labs/artiq/src/commit/fd66e127503b3db5947c7722faf16dc11aacafd3/artiq/firmware/riscv32ima-unknown-none-elf.json
• https://git.m-labs.hk/M-Labs/artiq-zynq/src/commit/27513e44ac155bbbe819c63c99727a32fcde8ad1/src/armv7-none-eabihf.json

but slightly altered for our use case and named after the hardware variants instead (i.e. kasli1.json, kasli2.json and kasli-soc.json).