Hacker News Reader

Hacker News

Comment by ddevault | Hacker News Reader

Parent Full thread

ddevault

Thanks for sharing your perspective. My comment was largely based on this discussion:

https://github.com/mesonbuild/meson/issues/2173

If you'd like to share a short summary of your thoughts, I'll update the article with your commentary.

View on HN

I would suggest not taking comments on random github threads as the position of a completely different project.

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.

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.)

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-variab...

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. :)

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...

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.

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-o...

I don't see anyone in that discussion who is on the Rust/Cargo teams.

I see a bunch of disagreement from people involved in gstreamer/meson (and some other non-team folks), which makes sense, disagreeing with something on your own project isn't external hostility, it's how decisionmaking works.

Also, disagreement != hostility.

Reply on news.ycombinator.com