cargo: Add support for target specific dependencies

[xclaesse]

No description provided.

[xclaesse]

CI passed, any objection?

[eli-schwartz]

First commit message has a typo: "causer" -> "caused".

I can't spot any obvious problems with the change but I would like to defer to @dcbaker on this as I don't know this subsystem very well.

[dcbaker]

The first patch seems fine.

The second means we can't reuse the same Meson generated between a host and build machine configuration, since now we've hard coded all of the machine info, nor could this parser be used in a generic meson translate command that takes a cargo manifest and produces a valid meson.build someone could use to start converting, that seems bad?

I'm in general concerned about hardcoding machine information into the cargo Interpreter, now that it's a a class and we store a single instance in Environment, although there isn't too much in this that looks difficult to refactor into a cross compatible soluton, apart from the thing above.

So, you have my RB for patches 1 and 3, but I'm absolutely not convinced by 2

[xclaesse]

@dcbaker cfg cannot be done in meson.build because it enables features which are global. By the point you interpret the generated meson.build it's too late. I think the meson translate idea is just a lost cause, that cannot work.

[xclaesse]

First commit message has a typo: "causer" -> "caused".

fixed.

[bonzini]

@xclaesse can you rebase this?

[bonzini]

The second means we can't reuse the same Meson generated between a host and build machine configuration, since now we've hard coded all of the machine info, nor could this parser be used in a generic meson translate command that takes a cargo manifest and produces a valid meson.build someone could use to start converting, that seems bad?

Adding a has_define method that checks cfg symbols would make it possible to look up cfgs in the compiler. That can be useful when converting build.rs files to Meson.

However, for the meson.build files that are generated during a build it makes sense to resolve cfg() more easily in the Cargo.toml parser.

[xclaesse]

@bonzini rebased, but we still need to convince @dcbaker.

[bonzini]

The cfg() conditionals are not what makes the Python implementation of the resolver necessary. Rather, it's needed because it needs to have a full view of all the involved Cargo.toml files, including the default-features keys and dep/xyz dependent features.

To be honest I don't yet fully understand why afd8944 and the features could not be passed as options even with the "Cargo interpreter" concept, but I agree about the necessity for a global resolver (which also needs to be two-phase, first add packages then build them, as in #14639).

Adding a has_define to Rust would let you query cfg symbols, and the "meson translate" concept remains feasible for everything after feature resolution. That is, you could generate a meson.build file that defines what to build from the available bin/tests/examples/doctests/... targets, the dependencies to override, etc.

I am not sure if that's enough to convince him. :)

Crates that have a build.rs will still need a manual translation, but that's not really avoidable since even the simplest build.rs often has a dependency on external crates for e.g. rustc version checks. :(

[bonzini]

Also I agree about with @dcbaker about the build vs. host machine issue, but (at least in the short term) the only solution I see for cross compilation is to basically duplicate the generated meson.build so that it can build the crate for both machines. So this should not get very much in the way, if at all.

[xclaesse]

The fact that cargo features are global means we cannot create any target until the whole dependency tree is resolved.

A depends on B, B enables feature F, A now also need dependency C, etc... it's a huge recursion that we can't resolve in meson.buil. At leasti don't see how.

[bonzini]

Tested this on https://github.com/bonzini/mandelbrot/, it does its job though there are still issues with conflicts in feature resolution

[xclaesse]

Let's merge this because it does the job and follows current design. We can always refactor later if someone comes with a better design idea.