Support for targeting multiple architectures

[negator]

(Moving from: acmcarther/cargo-raze#33)
It would be great if there was a straightforward way to add support for multiple architectures at once. A bit like how the Bazel --ios_multi_cpus works, but perhaps just allow an array of targets in Cargo.toml, which generates arch specific rules.

Answer from @acmcarther:

"I'm certainly open to this, but each target generates features, build scripts, and dependencies that are different, and I haven't had a chance to give enough though to the best way to organize the generated files. Do you have any ideas in that respect?"

[acmcarther]

I snuck an additional note into my response:

A long while ago, I evaluated the config_setting feature (that drives --ios_multi_cpus), and deferred making a decision. This was in part driven by the fact that there is a mismatch in the types of hardware introspection that Bazel historically supported versus cargo (i.e. a given cargo triple might not map exactly to a set of builtin config_setting values).

This is a great time to reevaluate.

[negator]

My first thought was to organize the generated rust rules into arch specific subdirectories under deps, like rust does with target. And generate a top level BUILD file that aliases the arch specific ones switching on target cpu specified by config_setting.

Something to the effect of:

-deps
  |-BUILD (aliases)
  |-arch_64_apple_ios
     |-BUILD
     |-remote
        |-...BUILD (referencing aliases)

As for the target triple mismatch, maybe its sufficient to statically map the most commonly used overlap between rustc and bazel.

The default bazel toolchain (as of 0.8.1) looks like:
darwin,
darwin_x86_64,
k8,
ios_x86_64,
ios_i386,
ios_armv7,
ios_arm64,
watchos_i386,
watchos_armv7k,
tvos_x86_64,
tvos_arm64,
armeabi-v7a

[akhilles]

Would it make more sense to do the select switching at the alias level or the generated BUILD file level? Also, rust_rules already has constraints based on target triples (https://github.com/bazelbuild/rules_rust/blob/master/rust/platform/platform.bzl). These can probably be used in the dependency selection.

[UebelAndre]

Hi, I'm interested in seeing this get done. Would it be possible to teach cargo-raze about the platform specific dependency tags in Cargo.toml?

Particularly:

[dependencies]
ferris-says = "0.2.0"

[target.x86_64-pc-windows-gnu.dependencies]
winhttp = "0.4.0"

[target.i686-unknown-linux-gnu.dependencies]
openssl = "1.0.1"

Here, 3 platforms would be targeted with the following dependencies

[host]
ferris-says = "0.2.0"

[x86_64-pc-windows-gnu]
ferris-says = "0.2.0"
winhttp = "0.4.0"

[i686-unknown-linux-gnu]
ferris-says = "0.2.0"
openssl = "1.0.1"

[host] would either be the detected auto-detected host platform or whatever is specified by the target argument in the [raze] section.

Then I think the crate_features, rustc_flags and other attributes of the generated rust_librarys would be wrapped in a switch() so that the correct flags would be paired with the correct platforms. Does that sound reasonable?

@acmcarther @damienmg interested in your thoughts.

[damienmg]

I think that makes sense I am somehow worry about the explosion of configuration but if it only keeps platform that should be manageable.

[UebelAndre]

@damienmg can you elaborate a bit more on what you're concerned about with the explosion of configuration?

[damienmg]

If there is a lot of configuration this create a very complex graph that can be long to generate and to analyze by bazel. I doubt this will be the case here as there should not be 700 platforms to handles :)

[rickwebiii]

This feature is pretty important to us, as many crates depend on winapi when building on Windows (a target we support).

[UebelAndre]

Does #212 solve for this issue?

[UebelAndre]

@acmcarther Do you know if this can be closed?

[dfreese]

I think we can close this. If there are any additional features or issues that come up with the current implementation those can be brought up in separate issues.