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

161–170 of 181 posts

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

#161

Post by tempest_ »

ninkendo wrote: post #146
dijit wrote: post #125

Earlier quoted context omitted.

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…

There is a large subset of devs who have worked their entire career on abstracted hardware which is fine I guess, just different domains.

The size of your L1/L2/L3 cache or the number of TLB misses doesn't matter too much if your python web service is just waiting for packets.

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

#162

Post by mathstuf »

eliemichel wrote: post #22
wg0 wrote: post #3

Yesterday I had to wrestle with CMake. But how this tool figures out where the header files and build instructions for the libraries are that are included? Any expected layout or industry wide consensus?

CMakes piles up various generations of idioms so there are multiple ways of doing it, but personally I’ve learned to steer away from find_package() and other magical functions. Get all your dependencies as subdirectories (whichever way you prefer) and use add_subdirectory(). Use find_package() only in so-called "config" mode where you explicitly instruct cmake where to find the config for large precompiled dependenci…

FD: I am a CMake developer.

Yes, config packages are better. But I think doing find_package everywhere is better. Assuming you install an SDK for others to use your project. If you're a "product", vendor away. The issue comes when you want to vendor X and Y and both vendor Z independently. Then you're stuck de-vendoring at least one and figuring out how to provide it yourself internally. IMO, better to just let Z make its own install tree and find it as a package from there.

One can write good Find modules, but there is some "taste" involved. I wish we had more good examples to use as templates.

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

#163

Post by tempest_ »

eslaught wrote: post #128
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.

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=nat…

If you get enough of them they can start to look like cattle.

Still, they are all the same breed.

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

#164

Post by adev_ »

criticalfault wrote: post #148
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…

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?

> skipping cmake completely? would this be feasible?

Feasible but difficult. CMake has a tremendous user mass, so you do want to be able to use a CMake-based project as a dependency. The CMake Target/Config export system expose CMake internals and make that difficult to consume a CMake built project without CMake.

The cleanest way to do that is probably what xmake is doing: Calling cmake and extract targets information from CMake to your own build system with some scripting. It is flaky but xmake has proven it is doable.

That's said: CPS should make that easier on the longer term.

Please also consider that CMake is doing a lot of work under the hood to contains compiler quirks that you will have to do manually.

> integration of other languages in the project?

Trying to integrate higher level languages (Python, JS) in package managers of lower level languages (C, C++) is generally a bad idea.

The dependency relation is inverted and interoperability betweens package managers is always poor. Diamond dependency and conflicting versions will become quickly a problem.

I would advise to just expose properly your build system with the properties I described and use a multi-language package manager (e.g Nix) or, at default, the higher level language package manager (e.g uv with a scikit-build-core equivalent) on top of that.

This will be one order of magnitude easier to do.

> how to handle qt?

Qt is nothing special to handle.

Qt is a multi language framework (C++, MOC, QML, JS and even python for PySide) and need to be handle as such.

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

#165

Post by forrestthewoods »

nnevatie wrote: post #143
forrestthewoods wrote: post #142

Earlier quoted context omitted.

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.

also agreed.

UV was so good it was just obviously significantly better.

All I really want is Bazel/Buck but in a simple and easy to use way. I feel like this can be done.

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

#166

Post by SpaceNoodled »

flohofwoe wrote: post #17
SpaceNoodled wrote: post #11

Earlier quoted context omitted.

My thoughts exactly. I thought this was going to be some new thing, but it's just yet another reason that I'll stick with Makefiles.

Do your Makefiles work across Linux, macOS and Windows (without WSL or MingW), GCC, Clang and MSVC, or allow loading the project into an IDE like Xcode or Visual Studio though? That's why meta-build-systems like cmake were created, not to be a better GNU Make.

Yes, yes, yes, yes, yes, LOL why, and I have never met an IDE that integrates nicely with a generic build file format.

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

#167

Post by pclmulqdq »

atiedebee wrote: post #151
pclmulqdq wrote: post #121

Earlier quoted context omitted.

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

I made a program with some inline assembly and tried O3 with clang once. Because the assembly was in a loop, the compiler probably didn't have enough information on the actual code and decided to fully unroll all 16 iterations, making performance drop by 25% because the cache locality was completely destroyed. What I'm trying to say, is that loop unrolling is definitely not a guarantee for faster code in exchange for…

Large blocks of inline assembly also destroy -O3. The compiler treats the asm statement as being essentially empty and makes decisions around it. Most inline asm is 1 instruction, so this is usually safe.

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

#168

Post by froh »

bluGill wrote: post #62
the__alchemist wrote: post #33

Earlier quoted context omitted.

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…

I didn't say the problem couldn't be solved. I said the problem can't be solved by one person. There is a difference. (maybe it can be solved by one person over a few decades)

sure about that?

your initial comment above focuses on the difficulty of the task, I didn't see mention of the need for collaboration to solve it.

maybe you had that in mind? the comment doesn't spell it out though...

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

#169

Post by MomsAVoxell »

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…

I agree with you to a degree, but I frame it slightly differently because there is a solution.

The problem is one of Tooling & Methodology. Not just tooling.

There is no divide between tools/methods - although there is often a massive conflict over methods, and thus tools, implying a relationship - but in fact both tooling and methodology need to be aligned or else poor tools are created.

There is much discussion about ‘the build problem’, but it is just as much an issue of solving ‘the method problem’.

For example, a vast majority of the problems of building software can be solved by using Docker (a method), or indeed adding new methods for various situations - i.e. embedded: compiler-onboard vs. cross-compiling, games: —march, etc.

I think the “I and Your” part of your position is ineffective - better to think of it as ‘a tool I/others want to use’ and ‘a method I/others agree to use’, where: tools and methods are aligned in equilibrium for the duration of the project (in an ideal case).

It’s ineffective because of the difference in effect between ‘want’ and ‘agree’ on that equilibrium.

Some methods, a person may not necessarily want to use - but agree to do so, because there is a local tool to assist with the method. Some tools, people will violently refuse to use because they despise the implied method and will never agree to it; sometimes, people get fired for not aligning methodology - but also often for writing a tool nobody (or hardly ever anybody) ever uses/can use/wants to use. (There’s a whole world of software that only one guy knows how to wrangle because they ‘built a better build system’…)

Apropos the “Yet Another C/C++ Configuration/Combobulator” problem, I tend to think the ‘problem with build systems’ is due to the avid desire to just build a new tool to force a new method rather than adopting an existing method and thus using existing tools, and, therefore in my opinion, the fewer new tools in this department, the better… but that’s just me, I’ve been wrangling C/C++ codebases since they were new languages, and I’ve seen some shit, kids ..

The solution is _always_ to align your methods with your fellow user-developers first and then work together on the tooling, old or new… because all software is social, and has a social responsibility to the user, and user-developer tools built to construct software socially, even more so.

Post reply on HN