Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I built a Cargo-like build tool for C/C++

github.com

Post reply on HN
Print view View original

91–100 of 181 posts

Re: Show HN: I built a Cargo-like build tool for C/C++

#91

Post by eqvinox »

gavinray wrote: post #29

The 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…

actually looks very similar to Meson [https://mesonbuild.com/], which is getting a lot of traction in FOSS [https://mesonbuild.com/Users.html]

e.g. from their docs:

  project('sdldemo', 'c',
          default_options: 'default_library=static')
  
  sdl2_dep = dependency('sdl2')
  sdl2_main_dep = dependency('sdl2main')
  
  executable('sdlprog', 'sdlprog.c',
             win_subsystem: 'windows',
             dependencies: [sdl2_dep, sdl2_main_dep])

Re: Show HN: I built a Cargo-like build tool for C/C++

#92

Post by izacus »

CoastalCoder wrote: post #88
adev_ wrote: post #49

Feedback 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…

> Never ever build in '-03 -march=native' by default. This is always a red flag and a sign of immaturity. Perhaps you can see how there are some assumptions baked into that statement.

Not assumptions, experience.

I fully concur with that whole post as someone who also maintained a C++ codebase used in production.

Re: Show HN: I built a Cargo-like build tool for C/C++

#93

Post by PufPufPuf »

CoastalCoder wrote: post #88
adev_ wrote: post #49

Feedback 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…

> Never ever build in '-03 -march=native' by default. This is always a red flag and a sign of immaturity. Perhaps you can see how there are some assumptions baked into that statement.

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.

Re: Show HN: I built a Cargo-like build tool for C/C++

#94

Post by maccard »

hyperhopper wrote: post #61
maccard wrote: post #57

Earlier quoted context omitted.

Given you're about to run a binary, it's no worse than that.

It is definitely worse. At leas a binary is constant, on your system, can be analyzed. Curl|sh can give you different responses than just curling. Far far worse

Only if you download an analyse it. You’re free to download the install script and analyze that too in the same way. The advantage that the script has is it’s human readable unlike the binary you’re about to execute blindly.

Re: Show HN: I built a Cargo-like build tool for C/C++

#95

Post by omcnoe »

bluGill wrote: post #26

Anyone 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…

There are so many reasons why C/C++ build systems struggle, but imo power is the last of them. "Powerful" and "scriptable" build systems are what has gotten us into the swamp!

* Standards committee is allergic to standardizing anything outside of the language itself: build tools, dependency management, even the concept of a "file" is controversial!

* Existing poor state of build systems is viral - any new build system is 10x as complex as a clean room design because you have to deal with all the legacy "power" of previous build tooling. Build system flaws propagate - the moment you need hacks in your build, you start imposing those hacks on downstream users of your library also.

Even CMake should be a much better experience than it is - but in the real world major projects don't maintain their CMake builds to the point you can cleanly depend on them. Things like using raw MY_LIB_DIR variables instead of targets, hacky/broken feature detection flags etc. Microsoft tried to solve this problem via vcpkg, ended up having to patch builds of 90% of the packages to get it to work, and it's still a poor experience where half the builds are broken.

My opinion is that a new C/C++ build/package system is actually a solvable problem now with AI. Because you can point Opus 4.6 or whoever at the massive pile of open source dependencies, and tell it for each one "write a build config for this package using my new build system" which solves the gordian knot of the ecosystem problem.

Re: Show HN: I built a Cargo-like build tool for C/C++

#96

Post by hmry »

PufPufPuf wrote: post #93
CoastalCoder wrote: post #88

Earlier quoted context omitted.

> Never ever build in '-03 -march=native' by default. This is always a red flag and a sign of immaturity. Perhaps you can see how there are some assumptions baked into that statement.

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.

Re: Show HN: I built a Cargo-like build tool for C/C++

#97

Post by cassepipe »

eqvinox wrote: post #91
gavinray wrote: post #29

The 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…

actually looks very similar to Meson [ https://mesonbuild.com/ ], which is getting a lot of traction in FOSS [ https://mesonbuild.com/Users.html ] e.g. from their docs: project('sdldemo', 'c', default_options: 'default_library=static') sdl2_dep = dependency('sdl2') sdl2_main_dep = dependency('sdl2main') executable('sdlprog', 'sdlprog.c', win_subsystem: 'windows', dependencies: [sdl2_dep, sdl2_main_dep])

Meson is a python layer over the ninja builder, like cmake can be. xmake is both a build tool and a package manager fast like ninja and has no DSL, the build file is just lua. It's more like cargo than meson is.

Re: Show HN: I built a Cargo-like build tool for C/C++

#100

Post by eqvinox »

cassepipe wrote: post #97
eqvinox wrote: post #91

Earlier quoted context omitted.

actually looks very similar to Meson [ https://mesonbuild.com/ ], which is getting a lot of traction in FOSS [ https://mesonbuild.com/Users.html ] e.g. from their docs: project('sdldemo', 'c', default_options: 'default_library=static') sdl2_dep = dependency('sdl2') sdl2_main_dep = dependency('sdl2main') executable('sdlprog', 'sdlprog.c', win_subsystem: 'windows', dependencies: [sdl2_dep, sdl2_main_dep])

Meson is a python layer over the ninja builder, like cmake can be. xmake is both a build tool and a package manager fast like ninja and has no DSL, the build file is just lua. It's more like cargo than meson is.

I didn't claim it was a package manager, just that it looked similar. The root post said "build tool", and that's what Meson is as well.

Other than that, both "python layer" and "over the ninja builder" are technically wrong. "python layer" is off since there is now a second implementation, Muon [https://muon.build/], in C. "over the ninja builder" is off since it can also use Visual Studio's build capabilities on Windows.

Interestingly, I'm unaware of other build-related systems that have multiple implementations, except Make (which is in fact part of the POSIX.1 standard.) Curious to know if there are any others.

Post reply on HN