The installation instructions being a `curl | sh` writing to the user's bashrc does not inspire confidence.
Given you're about to run a binary, it's no worse than that.
Show HN: I built a Cargo-like build tool for C/C++
61–70 of 181 posts
Re: Show HN: I built a Cargo-like build tool for C/C++
#62Anyone can make a tool that solves a tiny part of the problem. however the reason no such tool has caught on is because of all the weird special cases you need to handle before it can be useful. Even if you limit your support to desktop: OS/X and Windows that problem will be hard, adding various linux flavors is even more difficult, not to mention BSD. The above is the common/mainstream choices, there Haiku is going…
I will categorize this as a pattern I've seen which leads to stagnation, or is at least aiming for it. Usually these are built on one or more assumption which doesn't hold. The flow of this pattern: - Problem exists - Proposals of solutions, (varying quality), or not - "You can't just solve this. It's complicated! This problem must exist". (The post I'm replying to - Problem gets solved, hopefully. Anecdotes I'm choo…
Re: Show HN: I built a Cargo-like build tool for C/C++
#63Uses CMAKE, Sorry not for me. Call me old but i prefere good old make or batch. Maybe it's because i can understand those tools. Debugging CMAKE build problems made me hate it. Also i code for embedded CPU and most of the time CMAKE is just overkill and does not play well the compiler/binutils provided. The Platform independency is just not happening in those environments.
Re: Show HN: I built a Cargo-like build tool for C/C++
#64The least painful C/C++ build tool I've used is xmake https://github.com/xmake-io/xmake The reason why I like it (beyond ease-of-use) is that it can spit out CMakeLists.txt and compile_commands.json for IDE/LSP integration and also supports installing Conan/vcpkg libraries or even Git repos. set_project("myapp") set_languages("c++20") add_requires("conan::fmt/11.0.2", {alias = "fmt"}) add_requires("vcpkg::fmt", {alia…
Re: Show HN: I built a Cargo-like build tool for C/C++
#65In the age of AI tools like this are pointless. Especially new ones, given existence of make, cmake, premake and a bunch of others. C++ build system, at the core, boils down to calling gcc foo.c -o foo.obj / link foo.obj foo.exe (please forgive if I got they syntax wrong). Sure, you have more .c files, and you pass some flags but that's the core. I've recently started a new C++ program from scratch. What build system…
Re: Show HN: I built a Cargo-like build tool for C/C++
#66Please consider adding `cargo watch` - that would be a killer feature!
Re: Show HN: I built a Cargo-like build tool for C/C++
#67Heh, looks like cmake-code-generators are all the rage these days ;) Here's my feeble attempt using Deno as base (it's extremely opinionated though and mostly for personal use in my hobby projects): https://github.com/floooh/fibs One interesting chicken-egg-problem I couldn't solve is how to figure out the C/C++ toolchain that's going to be used without running cmake on a 'dummy project file' first. For some toolchai…
Re: Show HN: I built a Cargo-like build tool for C/C++
#68If you think cmake isn't very good, the solution isn't to add more layers of crap around cmake, but to replace it. Cmake itself exists because a lot of humans haven't bothered to read the gnu make manual, and added more cruft to manage this. Please don't add to this problem. It's a disease
Re: Show HN: I built a Cargo-like build tool for C/C++
#69Feedback 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…
Gentoo user: hold my beer.
Re: Show HN: I built a Cargo-like build tool for C/C++
#70If you think cmake isn't very good, the solution isn't to add more layers of crap around cmake, but to replace it. Cmake itself exists because a lot of humans haven't bothered to read the gnu make manual, and added more cruft to manage this. Please don't add to this problem. It's a disease
I'm all for shitting on CMake, but Jesus, to suggest Make as a replacement/improvement is an unhinged take.