@navi

Meh. I'd much rather put up with Cargo's limitations than try to understand the absolute madness of CMake configuration files. Cargo.toml is dead simple and that's how I damn well like it.

@natty @wyatt8740

@natty @wyatt8740 but hating on cargo is not misplaced even if rust is good, cargo is not inseparable from rust, and ignoring it's many flaws because it's the defacto standard build system for rust helps no one

rust would be so much better without cargo, which is why i'm hopeful for meson support, and for gccrs too because the mentality of the community around gccrs is different than the one around rustc

@natty @wyatt8740 cargo is only a good experience if you only write rust, with minimal interaction with other languages, without need of auxiliary files, and only for standard mainstream platforms, as support for conditional features based on platforms is also lacking, see "The Gripes" and "The Sad" on fish's rust port blog[1], which had to keep cmake in tree because of how inadequate cargo is as a build system / package manager

i'm not even talking about dynlink because it's not even necessary, hare for example statically links libraries, but they don't vendor them, instead looks for them in HAREPATH, usually /usr/src/hare

cargo only works well for developers that only need simple rust binaries and not much else, it's a design flaw, and one that after talking with many rust devs and lurking on many issues, the community seems to have very little want to fix

1: fishshell.com/blog/rustport/

I mean yeah we know about the Fish thing, but I'd say it's valid to use something else for places where it is wrapping around complex native stuff, especially when many such quirky things are often C libraries with a safe Rust wrapper. Fish porting the platform-dependent stuff to Rust was bound to be a bumpy road

But once you wrap the quirky stuff, you can essentially stick to doing these simple binaries just fine, and Cargo gets that done. Which is sort of the main point of Rust, isolating the dirty stuff in a box and using that box without having to know the insides of it

@natty @wyatt8740 there is no box, building c libraries in build.rs is not a box, not a solution, it's an ugly hack that breaks in the real world a lot

that is the major issue, real systems are not neat boxes, they're messy, they need proper handling, cargo provides nothing for that, and at the same time, it *refuses* to play along with other tools. it wants control of the source tree but it does not want to do all the work necessary to interface with the rest of the world

can't stick to doing simple binaries if your project doesn't ship only binaries, because those files can't be wrapped in a rust binary to begin with

> it wants control of the source tree

Um no. I have a Maven project with some Rust code, with pom.xml and Cargo.toml in the same folder. That works fine. Cargo DGAF that it's being invoked from another build system instead of directly, nor that the Rust sources are in a different folder than usual (because, again, there is both Rust and Java code in this project). It Just Works™, as Cargo usually does.

@natty @wyatt8740

@argv_minus_one

cargo does want to control the *rust* part of the source tree, cargo does not play nice with other build systems that want to manage the *rust* part of the source tree.

it's the whole reason meson couldn't "just wrap cargo" as rust people complained so much. it lacks basic options and flexibility required to be a proper secondary build system

@navi

What basic options and flexibility do you have in mind?