3 ms·
To be blunt, if anything it might be you who live in a closed bubble. Builds that require ad-hoc functionality is the default. It’s extremely rare that everyth
by kaba0 2y ago
To be blunt, if anything it might be you who live in a closed bubble.
Builds that require ad-hoc functionality is the default. It’s extremely rare that everything fits nicely into “cargo build” or other single language build tools’ model. And while these often have escape hatches, at that point you have to write imperative code with no caching and parallelization that is literally the job of a build tool.
- rykad 2y agoI've been doing jvm apps for almost 20yrs... What builds need to do and what people made the builds do are completely different things. I don't remember a single project I was involved in that could not had had a simpler build...
- elygre 2y agoTrue. In our example we didn’t have to generate online help and pdf manuals from the same asciidoctor sources. But when we chose to, we really needed the customization that cradle offered.
- pkolaczk 2y ago> It’s extremely rare that everything fits nicely into “cargo build” 161538 crates do not agree with you ;)
- kaba0 2y agoWhich are mostly small, isolated library code, whose purpose is to be easily incorporated into larger programs. That’s the 90% easy path of build tools. What about a large project built over 6 years by 50 people, and that has to use some obscure technology to communicate with company A, and another one that has an idiotic build step?
- pkolaczk 2y ago> Which are mostly small, isolated library code, whose purpose is to be easily incorporated into larger programs. Which is how software should be generally made - from small and simple things, not from huge behemoths that contain the kitchen sink and brew coffee.
- jfyasdfuwas 2y agoThe apps are also built using cargo build. For your outlandish use cases you can use Bazel.