Sensitive content Reveal/hide

Sensitive content Reveal/hide

Sensitive content Reveal/hide

Sensitive content Reveal/hide

We didn't build ruffle but we've used chromium from source

The point?

Our target dir is 28 megs

What

Ours is 8 gigs and we've built thousands of crates for like a dozen different projects

I'm sorry but I don't see how cargo is some evil boogeyman while native package managers or CMake are suddenly saints

@natty @wyatt8740 cargo is awful at things any package manager should do tho, it's overly rigid and only really works for `cargo install` and *very* simplistic build requirements, but for some reason it's treated as the be all end all for rust building and packaging

like 8 years later and we still can't install auxiliary files (like manpages) with cargo: github.com/rust-lang/cargo/iss…, packages constantly download c or c++ crates and build them ad-hoc in build.rs, cargo doesn't have the correct abstractions for a package manager, it isn't nearly as portable as meson/muon or even autotools, and cargo itself has nothing to do with memory safety, rust has, rust is quite the good language, cargo is awfully designed

@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