Hacker News Reader

Comment by steveklabnik | Hacker News Reader

There's a lot of stuff I could say here, but I'll stick to

> Attempts to integrate it with other build systems have been met with hostility from the Rust & Cargo teams.

This is very much not true. We've put in a ton of work to support this. Arguably, we've put in too much design work and not enough implementation work; we've had a few different attempts at making this work even better than it does today, and we haven't finished them up. But this is very much something that is cared about and desired by the team.

It was literally on the 2017 roadmap: https://blog.rust-lang.org/2017/02/06/roadmap.html

> Rust should integrate easily into large build systems. Plans include working with large companies incorporating Rust to understand how best to equip Cargo to smooth the process.

I don't know how this is framed as "hostility".

As one example of the work done here: https://github.com/rust-lang/cargo/issues/5579

View on HN

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.

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.

Does build-plan help with the case of including an artifact from another build system (e.g. data file for code-generation like SVD or libs to link against)? What about someone not using build-plan but publishing crates, whether external or internal?

Speaking of, alternative crate indexes are something I think we need to do at some point for improved corporate support. It'll be interesting to explore the requirements. Some I can think of include

- Publish internal-only crates - Some companies might want purely internal mirroring (for secured systems) - Some companies might want a read-through cache to self-host what they use (for life-cycle management) - Some companies might want to exclude crates (for extra-cautious licensing validation) which could make it hard to use anything unless we can also transitively exclude things

build-plan is meant to be able to expose to an external build system the stuff that Cargo would want to build; it's not meant to talk about artifacts from other build systems. It's meant to help Rust fit in there, not to control other parts of the build.

> Speaking of, alternative crate indexes are something I think we need to do at some point for improved corporate support.

Absolutely! We accepted an RFC here, and there's an unstable implementation https://github.com/rust-lang/rfcs/blob/master/text/2141-alte...

not a great article, but also not a great response

articles like what was posted are frustrating and can clearly hit a nerve, but instead of being defensive, try to use the feedback as indication that the work that's been done may just not be recognized, instead of it not being done

I think in general this is good advice, but my goal with the above is to do exactly that: provide information about what it is that we’re doing.

There are constructive comments and then there are very opinionated rants. Eventually you just have to realized that you cannot always make everyone happy, in this case, a grumpy C programmer who tries to start a flame war.

Reply on news.ycombinator.com