Rust module : Add support for cargo subprojects #8514
Conversation
|
This pull request introduces 9 alerts when merging a8308e6 into 4fda4f5 - view on LGTM.com new alerts:
|
|
This pull request introduces 9 alerts when merging cc776fb into a1c8376 - view on LGTM.com new alerts:
|
dcbaker
force-pushed
the
wip/2021-01/rust-module-cargo
branch
from
cc776fb to
0ba8ef5
Compare
|
This pull request introduces 11 alerts when merging 0ba8ef5 into 8fa7f3a - view on LGTM.com new alerts:
|
|
This pull request introduces 8 alerts when merging 6f14ace into 8fa7f3a - view on LGTM.com new alerts:
|
|
Does someone who actually knows how this should work want to review this? |
I'm using a type alias for now, as I plan to change the type later in this series
This module implements an AST building API that is somewhat nice to work with. There's still some things here that could use cleanup, but in general it's okay to work with. TODO: needs some documentation
cargo is going to use ast for options, which cmake doesn't.
This is a giant blob of code. It basically reads a cargo manifest, and then produces a meson.build from that manifest.
This adds the ability to do `import('rust').subproject('foo')`, like
cmake.
Giant blob of stuff all shoved into one giant commit
This uses pytest not unittest, unittest is such a pain in the ass and pytest is so much nicer..
dcbaker
force-pushed
the
wip/2021-01/rust-module-cargo
branch
from
6f14ace to
2ed446a
Compare
|
This pull request introduces 8 alerts when merging 2ed446a into 619e05c - view on LGTM.com new alerts:
|
|
This pull request introduces 7 alerts when merging 17f862b into 619e05c - view on LGTM.com new alerts:
|
|
Related to #2173 For fetching crates, there is cargo-download. I was looking into setting up an embedded rust project with meson (to make it easy to integrate into C/C++ projects), and the lack of crates support is annoying. I was hacking up a way to build the crates I need with a combination of |
|
I might look at cargo download. My preference would be to not have any dependency on cargo at all, but we'll just have to see once this is actually in a state to land. |
|
@dcbaker I don’t think that avoiding a Cargo dependency is realistic. Cargo does a massive amount of work related to stuff like dependency resolving, some of which is even (if I understand it correctly) NP-complete (so you won’t be able to practically reimplement it in pure Python without massive performance hits). What I do consider realistic is building Rust code that vendors its dependencies (via |
|
Handling rust dependencies as subprojects means that none of this matters. Subprojects are a form of vendoring which uses pinned versions, so the only dependency resolution involved is "use it? Yes or no?" And if yes, "here is exactly one url which may be used to acquire it". |
|
Right, and my plan initially is to use cargo vendor to do that vendoring. Long term i would like meson wrap to be able to handle it, which is not run at build or compile time, so the cost is paid once and then checked into git, making the cost relatively small |
|
FYI c.f. https://github.com/kolloch/crate2nix and https://github.com/NixOS/nixpkgs/tree/master/pkgs/build-support/rust/build-rust-crate, which build Rust crates from the lockfile with little use of Cargo itself. |
|
Hi @dcbaker, what is the state of this? I might be able to spend some time on it. It seems plausible to rely solely on |
|
This should really be closed in favor of #10151 The basic problem I've run into is that so many of the core types are really tied up in the interpreter, so I wrote all of the code to fix the build.py problem, and that's stalled. If you wanna help me figure out why #10714 all works fine for me but fails utterly in CI that would be super helpful :) |
|
Ok in the past I tried bisecting the failure, I can try doing that here too. |
I want to preface this that this is still a work in progress, there's a lot left to do, but I have been able to compile a couple of simple demo projects with this, so we've gotten to the point that "something works". I'm sharing this mostly to get a little visibility into the work.
The end goal is to be able to build Rust crates as fully native Meson subprojects, there's still some work to do on a lot of fronts, but it's getting there.