4 ms·

I didn’t read the entire thread, but if I understood the gist of it, it seems like an anti-pattern is being asked for, and it would be an anti-pattern when mixi

I didn’t read the entire thread, but if I understood the gist of it, it seems like an anti-pattern is being asked for, and it would be an anti-pattern when mixing any languages. What it seems they want is the ability to mix Rust and C in the same build chain, not treat each as a separate build artifact and link at the end. I’ve never had a problem modeling things with Makefiles, having the Rust artifact target be built by Cargo and then linking with the standard toolchain for C in the Makefile. I’m clearly missing some context, as this works really well.

steveklabnik 8y ago
Yes, there's a ton of ways that you can do this. Most successful integrations thus far have done exactly that: you have a target for your Rust code, it calls out to Cargo and does its thing, and then links it in. I believe that you're right that the Meson folks want to use rustc like they use cc, and use Meson for all of the stuff that's not "compile this, please." This can work well as long as you're writing all of your own code. The issue is that most people like Cargo, and like using Cargo, and so virtually all open-source projects are built around Cargo. This is not unlike if you're a Meson fan, but you want to use an open source project that uses CMake for its build, and so it's only really set up to use CMake. (At least, in my understanding.)
- bluejekyll 8y ago
  Well, then the comment they made about essentially rewriting Cargo is probably accurate. Doesn’t seem like it’s a valuable contribution to their end goal though. I do want to point out (for others, you know this) that Cargo has a lot of environment variables that can be used to improve its usage inside other build systems, e.g. using a shared target directory for reusing compilation of dependencies: https://doc.rust-lang.org/cargo/reference/environment-variables.html https://doc.rust-lang.org/cargo/reference/environment-variab...
  - steveklabnik 8y ago
    Right, that's why we introduced the build plan feature, so that you don't have to re-implement Cargo, you can use Cargo to spit out the stuff you need instead. :)
rhn_mk1 8y ago
There's a blog post diving more into the details of language cooperation from Meson's perspective here: http://nibblestew.blogspot.com/2019/02/why-is-cross-language-cooperation-so.html http://nibblestew.blogspot.com/2019/02/why-is-cross-language...
- bluejekyll 8y ago
  Thanks for posting that. I understand what they’re getting at, but they didn’t quite convince me in the opening that this isn’t a build structure problem vs. a build tool issue. There’s a lot of work to do what they’re trying to achieve, and at best you’ll possibly get a faster build? Maybe it’s easier to configure? Though that also wasn’t obvious to me that there would be a large gain there.
  - rhn_mk1 8y ago
    There's another post explaining why Meson is trying to do what it is trying to do. My takeaway was that having a single universal build system is easier to deal with than multiple splintered ones, full of duplicated effort: http://nibblestew.blogspot.com/2019/02/on-possible-futures-of-meson.html http://nibblestew.blogspot.com/2019/02/on-possible-futures-o...

steveklabnik 8y ago

Yes, there's a ton of ways that you can do this. Most successful integrations thus far have done exactly that: you have a target for your Rust code, it calls out to Cargo and does its thing, and then links it in. I believe that you're right that the Meson folks want to use rustc like they use cc, and use Meson for all of the stuff that's not "compile this, please." This can work well as long as you're writing all of your own code. The issue is that most people like Cargo, and like using Cargo, and so virtually all open-source projects are built around Cargo. This is not unlike if you're a Meson fan, but you want to use an open source project that uses CMake for its build, and so it's only really set up to use CMake. (At least, in my understanding.)

bluejekyll 8y ago
Well, then the comment they made about essentially rewriting Cargo is probably accurate. Doesn’t seem like it’s a valuable contribution to their end goal though. I do want to point out (for others, you know this) that Cargo has a lot of environment variables that can be used to improve its usage inside other build systems, e.g. using a shared target directory for reusing compilation of dependencies: https://doc.rust-lang.org/cargo/reference/environment-variables.html https://doc.rust-lang.org/cargo/reference/environment-variab...
- steveklabnik 8y ago
  Right, that's why we introduced the build plan feature, so that you don't have to re-implement Cargo, you can use Cargo to spit out the stuff you need instead. :)

rhn_mk1 8y ago

There's a blog post diving more into the details of language cooperation from Meson's perspective here: http://nibblestew.blogspot.com/2019/02/why-is-cross-language-cooperation-so.html http://nibblestew.blogspot.com/2019/02/why-is-cross-language...

bluejekyll 8y ago
Thanks for posting that. I understand what they’re getting at, but they didn’t quite convince me in the opening that this isn’t a build structure problem vs. a build tool issue. There’s a lot of work to do what they’re trying to achieve, and at best you’ll possibly get a faster build? Maybe it’s easier to configure? Though that also wasn’t obvious to me that there would be a large gain there.
- rhn_mk1 8y ago
  There's another post explaining why Meson is trying to do what it is trying to do. My takeaway was that having a single universal build system is easier to deal with than multiple splintered ones, full of duplicated effort: http://nibblestew.blogspot.com/2019/02/on-possible-futures-of-meson.html http://nibblestew.blogspot.com/2019/02/on-possible-futures-o...