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

121–130 of 181 posts

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

#121

Post by pclmulqdq »

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.

If you have a lot of "data plane" code or other looping over data, you can see a big gain from -O3 because of more aggressive unrolling and vectorization (HPC people use -O3 quite a lot). CRUD-like applications and other things that are branchy and heavy on control flow will often see a mild performance regression from use of -O3 compared to -O2 because of more frequent frequency hits due to AVX instructions and larger binary size.

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

#122

Post by alonsovm »

randerson_112 wrote: post #79

Thank you everyone for the feedback so far! I just wanted to say that I understand this is not a fully cohesive and functional project for every edge case. This is the first day of releasing it to the public and it is only the beginning of the journey. I do not expect to fully solve a problem of this scale on my own, Craft is open source and open to the community for development. I hope that as a community this can g…

this project is something i'd do, i had the idea about the same time as you did, "why something like cargo for c++ doesn't exist?" and you did it, thanks I guess.

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

#123

Post by resonancel »

Can't take this lib seriously when there're lots of gems like these in the codebase.

  // Open source directory
      dir_t* dir = open_dir(source_dir);

  // Find where dot is
      char* dot = strrchr(file, '.');
I thought ShowHN had banned LLM-generated contents, I can't be more wrong.

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

#124

Post by bluGill »

omcnoe wrote: post #95
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 syste…

No scripts sounds nice until you are doing something weird that the system doesn't cover. Cmake is starting to get all the possible weirdness right without scripts but there are still a few cases it can't handle.

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

#125

Post by dijit »

ninkendo wrote: post #108
dijit wrote: post #107

Earlier 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.

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.

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

#126

Post by teo_zero »

eqvinox wrote: post #102
tempest_ wrote: post #101

Earlier 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.

I'm willing to hear arguments for your approach? it certainly has scale issues when you need to support larger deployments. [P.S.: the way I understand the words, "shipping" means "passing it off to someone else, likely across org boundaries" whereas what you're doing I'd call "deploying"]

So, do you see now the assumptions baked in your argument?

> when you need to support larger deployments

> shipping

> passing it off to someone else

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

#127

Post by Panzerschrek »

> 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.

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

#128

Post by eslaught »

tempest_ wrote: post #101
eqvinox wrote: post #90

Earlier 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.

Just popping in here because people seem to be surprised by

> 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.

This is exactly the use case in HPC. We always build -march=native and go to some trouble to enable all the appropriate vectorization flags (e.g., for PowerPC) that don't come along automatically with the -march=native setting.

Every HPC machine is a special snowflake, often with its own proprietary network stack, so you can forget about binaries being portable. Even on your own machine you'll be recompiling your binaries every time the machine goes down for a major maintenance.

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

#130

Post by nnevatie »

kjksf wrote: post #48

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

The same AI tool could have written a de-facto CMakeLists.txt file for you.
Post reply on HN