Relevant XKCD: https://xkcd.com/927/
Show HN: I built a Cargo-like build tool for C/C++
141–150 of 181 posts
Re: Show HN: I built a Cargo-like build tool for C/C++
#142Cmake is infamously not a build system. It is a build system generator. This is now a build system generator generator. This is the wrong solution imho. The right solution is to just build a build system that doesn’t suck. Cmake sucks. Generating suck is the wrong angle imho.
Cmake might suck, but is arguably the de-facto now. It's not standard, since the C++ committee does not want to deal with the real world (tooling).
Python was also a shitshow and UV became the new standard in literally less than a year.
That’s an existence proof that a new tool that doesn’t suck can take over an ecosystem.
Re: Show HN: I built a Cargo-like build tool for C/C++
#143Earlier quoted context omitted.
Cmake might suck, but is arguably the de-facto now. It's not standard, since the C++ committee does not want to deal with the real world (tooling).
Python was also a shitshow and UV became the new standard in literally less than a year. That’s an existence proof that a new tool that doesn’t suck can take over an ecosystem.
Completely agreed. However, typically a new tool needs to be significantly better for that to happen. In many ways, I see Meson already being that but it hasn't really gained traction at scale.
Re: Show HN: I built a Cargo-like build tool for C/C++
#144Given how pathetic toml is with arrays, kinda sad people go with it.
Re: Show HN: I built a Cargo-like build tool for C/C++
#145> You describe your project in a simple craft.toml I don't like it. Such format is generally restricted (is not Turing-complete), which doesn't allow doing something non-trivial, for example, choosing dependencies or compilation options based on some non-trivial conditions. That's why CMake is basically a programming language with variables, conditions, loops and even arithmetic.
While I do get why CMake is a scripted build system, I cannot help but notice that other languages don't need it. In Rust, you have Cargo.toml, in go, it's a rather simple go.mod. And even in embedded C, you have platformio which manages to make due with a few .ini files. I would honestly love to see the cpp folks actually standardizing a proper build system and dependency manager. Today, just building a simple QT ap…
Platformio is not simple by any means. That few .ini files generate a whole bunch of python, and this again relies on scons as build system.
That's a nice experience as long as you stay within predefined, simple abstractions that somebody else provided. But it is very much a scripted build system, you just don't see it for trivial cases.
For customizations, let alone a new platform, you will end up writing python scripts, and digging through the 200 pages documentation when things go wrong.
Re: Show HN: I built a Cargo-like build tool for C/C++
#146Earlier quoted context omitted.
… not everyone uses the cloud? Some people, gasp , run physical hardware, that they bought.
And all your deployed and dev machines run the same spec- same CPU entirely? And you use them for remote development? I think this is highly unusual.
Lots of organizations buy many of a single server spec. In fact that should be the default plan unless you have a good reason to buy heterogeneous hardware. With the way hardware depreciation works they tend to move to new server models “in bulk” as well, replacing entire clusters/etc at once. I’m not sure why this seems so foreign to folks…
Nobody is saying dev machines are building code that ships to their servers though… quite the opposite, a dev machine builds software for local use… a server builds software for running on other servers. And yes, often build machines are the same spec as the production ones, because they were all bought together. It’s not really rare. (Well, not using the cloud in general is “rare” but, that’s what we’re discussing.)
Re: Show HN: I built a Cargo-like build tool for C/C++
#147KDE already has a meta-build tool for C++ called Craft, which handles dependency management and cross - compilation for CMake-built applications and libraries.
Re: Show HN: I built a Cargo-like build tool for C/C++
#148Feedback of someone who is used to manage large (>1500) software stack in C / C++ / Fortran / Python / Rust / etc: - (1) Provide a way to compile without internet access and specify the associated dependencies path manually. This is absolutely critical. Most 'serious' multi-language package managers and integration systems are building in a sandbox without internet access for security reasons and reproducibility reas…
since you have a lot of experience, can I ask what do you think about this:
- skipping cmake completely? would this be feasible?
- integration of other languages in the project?
- how to handle qt?
Re: Show HN: I built a Cargo-like build tool for C/C++
#149Earlier quoted context omitted.
I build on the exact hardware I intend to deploy my software to and ship it to another machine with the same specs as the one it was built on. I am willing to hear arguments for other approaches.
Not the OP, but: -march says the compiler can assume that the features of that particular CPU architecture family, which is broken out by generation, can be relied upon. In the worst case the compiler could in theory generate code that does not run on older CPUs of the same family or from different vendors. -mtune says "generate code that is optimised for this architecture" but it doesn't trigger arch specific featur…
> Not the OP, but: -march says the compiler can assume that the features of that particular CPU architecture family, which is broken out by generation, can be relied upon. In the worst case the compiler could in theory generate code that does not run on older CPUs of the same family or from different vendors.
Or on newer CPUs of the same vendor (e.g. AMD dropped some instructions in Zen that Intel didn't pick up) or even in different CPUs of the same generation (Intel market segmenting shenanigans with AVX512).
Re: Show HN: I built a Cargo-like build tool for C/C++
#150Feedback of someone who is used to manage large (>1500) software stack in C / C++ / Fortran / Python / Rust / etc: - (1) Provide a way to compile without internet access and specify the associated dependencies path manually. This is absolutely critical. Most 'serious' multi-language package managers and integration systems are building in a sandbox without internet access for security reasons and reproducibility reas…
As someone who has also spent two decades wrangling C/C++ codebases, I wholeheartedly agree with every statement here. I have an even stronger sentiment regarding cross compilation though - In any build system, I think the distinction between “cross” and “non-cross” compilation is an anti-pattern. Always design build systems assuming cross compilation. It hurts nothing if it just so happens that your host and target…
Amen. It always baffled me that cross compiling was ever considered a special, weird, off-nominal thing. I’d love to understand the history of that better, because it seems like it should have been obvious from the start that building for the exact same computer you’re compiling from is a special case.