“Show HN” has really become a Claude code showcase in the last 6 months, maybe it's time to sunset the format at this point …
Yup, I read "— think Cargo, but for C/C++." and closed the tab.
The em dash - it's always the em dash.
Show HN: I built a Cargo-like build tool for C/C++
131–140 of 181 posts
Re: Show HN: I built a Cargo-like build tool for C/C++
#132Cmake 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).
Re: Show HN: I built a Cargo-like build tool for C/C++
#133Earlier quoted context omitted.
I'm all for shitting on CMake, but Jesus, to suggest Make as a replacement/improvement is an unhinged take.
I'm suggesting that people creating build systems read the make manual. Surely this isn't controversial?
People using CMake might want to build the same code on multiple platforms - this is trivially achievable, unlike with Make.
Re: Show HN: I built a Cargo-like build tool for C/C++
#134> 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 app is usually a daunting task, and other compiled ecosystems show us it doesn't have to be.
Re: Show HN: I built a Cargo-like build tool for C/C++
#135Can it handle modules?
Re: Show HN: I built a Cargo-like build tool for C/C++
#136Earlier quoted context omitted.
The only time I used -march=native was for a university assignment which was built and evaluated on the same server, and it allowed juicing an extra bit of performance. Using it basically means locking the program to the current CPU only. However I'm not sure about -O3. I know it can make the binary larger, not sure about other downsides.
-O3 also makes build times longer (sometimes significantly), and occasionally the resulting program is actually slightly slower than -O2. IME -O3 should only be used if you have benchmarks that show -O3 actually produces a speedup for your specific codebase.
This various a lot between compilers. Clang for example treats O3 perf regressions a bugs In many cases at least) and is a bit more reasonable with O3 on. GCC goes full mad max and you don't know what it's going to do.
Re: Show HN: I built a Cargo-like build tool for C/C++
#137Feedback 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…
Agree with the feedback.
Also the problem isn't creating a cargo like tool for C and C++, that is the easy part, the problem is getting more userbase than vcpkg or conan for it to matter for those communities.
Re: Show HN: I built a Cargo-like build tool for C/C++
#138Earlier quoted context omitted.
What assumptions would that be? Shipping anything built with -march=native is a horrible idea. Even on homogeneous targets like one of the clouds, you never know if they'll e.g. switch CPU vendors. The correct thing to do is use microarch levels (e.g. x86-64-v2) or build fully generic if the target architecture doesn't have MA levels.
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.
So I get you don't do neither cloud, embedded, game consoles, mobile devices.
Quite hard to build on the exact hardware for those scenarios.
Re: Show HN: I built a Cargo-like build tool for C/C++
#139Earlier quoted context omitted.
What?! seriously?! I’ve never heard of anyone doing that. If you use a cloud provider and use a remote development environment (VSCode remote/Jetbrains Gateway) then you’re wrong: cloud providers swap out the CPUs without telling you and can sell newer CPUs at older prices if theres less demand for the newer CPUs; you can’t rely on that. To take an old naming convention, even an E3-Xeon CPU is not equivalent to an E5…
… not everyone uses the cloud? Some people, gasp , run physical hardware, that they bought.
So you buy exact same generation of Intel and AMD chips to your developers than your servers and your cutomsers? And encode this requirement into your development process for the future?
Re: Show HN: I built a Cargo-like build tool for C/C++
#140I have to say, since CMakes FetchContent module has been available I have not had a need for a dependency manager outside of CMake itself.
What exactly is it you do/need that can't be reasonably solved using the FetchContent module?
https://cmake.org/cmake/help/latest/module/FetchContent.html