Added module for abi constraint values

[UebelAndre]

This pull-requests adds constraint_value flags for common abi flags. Defining these in the @platforms repository avoids other rules from needing to define custom constraints and/or avoids each repository defining project specific constraints.

closes https://github.com/bazelbuild/platforms/issues/38

[bsilver8192]

gnueabihf commonly means all of these, of the ones written:

• eabi
• eabihf
• elf
• gnu
• gnu_ilp32 (all 3 types 32 bits, but this term is usually only applied to 64-bit instruction sets, so maybe not)
• gnueabi
• gnueabihf

Some of these might be meant as opposites of each other, but that's unclear. Even if it was written in a comment, I suspect people will end up picking the wrong ones via copy/paste a lot.

Also, AFAIK a platform can only have a single of these constraint_values, which doesn't seem like it works very well for these.

I don't have a good proposal here, but I think this will be confusing and worse than the status quo.

[UebelAndre]

@bsilver8192 thanks so much for taking a look! The values here were all taken from platform triples listed on https://doc.rust-lang.org/nightly/rustc/platform-support.html

While it'd be nice to represent everything there, I'd be fine with reducing this PR to common and less controversial values. Maybe just the following for starters and have deeper conversations about more unique values?:

• gnu
• musl
• msvc

[bsilver8192]

While it'd be nice to represent everything there, I'd be fine with reducing this PR to common and less controversial values. Maybe just the following for starters and have deeper conversations about more unique values?:

• gnu
• musl
• msvc

What semantics are you proposing for each one? Those strings in the ABI part of a triple mean different things depending on the rest of the triple, so I don't think we can define them that way. Leaving it up to Bazel users to come up with their own meanings seems counterproductive, because you end up with conflicts when trying to use rule ecosystems together. Also, there are lots of places that use "target triples" with subtly different, conflicting meanings and sets of choices for each component, for example:

• Clang
• Rust (not the same as Clang, https://github.com/rust-lang/rust-bindgen/blob/c27578fac5372575e3caa933a83eac931ae3b53f/src/lib.rs#L2233 has some differences)
• GCC
• Multiarch

[UebelAndre]

What semantics are you proposing for each one? Those strings in the ABI part of a triple mean different things depending on the rest of the triple, so I don't think we can define them that way. Leaving it up to Bazel users to come up with their own meanings seems counterproductive, because you end up with conflicts when trying to use rule ecosystems together. Also, there are lots of places that use "target triples" with subtly different, conflicting meanings and sets of choices for each component, for example:

* Clang

* Rust (not the same as Clang, https://github.com/rust-lang/rust-bindgen/blob/c27578fac5372575e3caa933a83eac931ae3b53f/src/lib.rs#L2233 has some differences)

* GCC

* Multiarch

That's a great question. I personally don't have a super strong opinion, for Rust I think rules_rust could probably provide some aliases to provide more familiar constraints and would expect other rules/languages to do the same. the @platforms repository should have the simplest and most common values to really benefit the larger community here.

[aiuto]

This has lingered too long. I think we should not merge this as is, but take a step back and wait for a proposal that talks about what need a new abi space is serving problems, and shows how it will be applied to multiple languages (not just rust) and oses. In particular, I would like to see the edges, like cross compilation and building for mixed C++, Go & rust applications.