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

A different approach to building C++ projects

rachelbythebay.com

Post reply on HN
Print view View original

41–50 of 74 posts

Re: A different approach to building C++ projects

#41

Post by kibwen »

pjmlp wrote: post #30
kibwen wrote: post #25

Earlier quoted context omitted.

I'm unsure what this is trying to say. You appear to be in begrudging agreement that Rust is commonly mixed with other languages?

That cargo is not enough, and polyglot codebases either use something else, or have quite extensive uses of build.rs.

No, most polyglot codebases use Cargo. For something massive like Android that has gone so far as to implement its own build system, no third-party build system would be sufficient, so focusing on Cargo is irrelevant. The fact is, Cargo has always been deliberately and consciously designed to be merely an abstraction over rustc, specifically in order to accommodate opinionated users who would be better served by invoking rustc directly. They're following exactly the workflow that the Rust developers intended, because this saves the Cargo developers from having to perfectly anticipate every potential user's needs, which would be impossible. Rust does the right thing here.

Re: A different approach to building C++ projects

#43

Post by flohofwoe »

tkuraku wrote: post #31
jbandela1 wrote: post #4

One of the nice things that Visual C++ has is #pragma comment(lib, "xxx.lib") You can specify it in a header file for the library. That way if you include the header file, the library mentioned will automatically get linked as long as it is somewhere in the library search path. I have found myself wishing that GCC would also get something like this.

I really don't like this feature. I like knowing what and where things are linked explicitly.

This could be handled through a --verbose flag on the linker (and maybe --dry-run).

Re: A different approach to building C++ projects

#44

Post by db48x »

davedx wrote: post #38
matthewaveryusa wrote: post #33

Earlier quoted context omitted.

This is wisdom right here. It's tragedy of the commons. I find that the real problem is no one wants to properly learn how their build system works. I don't care if it's make, cmake or bazel -- whatever it is, you need to _learn_ it. I've worked with folks that have 20 years of experience, fantastic C/C++ developers, that look at a makefile and say "Ugh what is this complicated mess, can you do it in cmake or bazel o…

> whatever it is, you need to _learn_ it. The problem in my experience is you invest time learning build system A, then a year later build system B comes out, and not only do you need to relearn a bunch of stuff again, often build system B does some of the stuff of system A but not all of it, plus it does new stuff that you've never encountered before. Then this cycle repeats, endlessly, and every new team you join h…

Who says you have to learn tool B just because it was released? Just ignore it and keep using A.

Re: A different approach to building C++ projects

#45

Post by DarkNova6 »

davedx wrote: post #38
matthewaveryusa wrote: post #33

Earlier quoted context omitted.

This is wisdom right here. It's tragedy of the commons. I find that the real problem is no one wants to properly learn how their build system works. I don't care if it's make, cmake or bazel -- whatever it is, you need to _learn_ it. I've worked with folks that have 20 years of experience, fantastic C/C++ developers, that look at a makefile and say "Ugh what is this complicated mess, can you do it in cmake or bazel o…

> whatever it is, you need to _learn_ it. The problem in my experience is you invest time learning build system A, then a year later build system B comes out, and not only do you need to relearn a bunch of stuff again, often build system B does some of the stuff of system A but not all of it, plus it does new stuff that you've never encountered before. Then this cycle repeats, endlessly, and every new team you join h…

ant is still being used in the Java space? That would be new to me. Gradle is just enforced by google for Android deployment for some arbitary reason.

For 90% of use-cases nothing beats the simplicity of Maven.

Re: A different approach to building C++ projects

#46

Post by IshKebab »

kibwen wrote: post #25
pjmlp wrote: post #20

Earlier quoted context omitted.

So much common that Google had to create their own integrations for Android and Fuchsia. I bet the announced Chrome efforts will again, require another adaptation.

I'm unsure what this is trying to say. You appear to be in begrudging agreement that Rust is commonly mixed with other languages?

He's saying that Cargo doesn't really help at all with that mixing. Integrating Rust into a multi-language build system is indeed quite a pain. You have a few bad options:

* Drive everything with Cargo using `build.rs`. This sort of works but it's pretty horrible.

* Give up and just have your main build system run `cargo build`. This is what I normally do but again it's not ideal because it doesn't really integrate properly with your main build system.

* Give up on Cargo entirely. This is what Bazel does, and it's probably the most robust solution but it's still not ideal because most of the Rust ecosystem expects you to use Cargo (e.g. rust-analyzer).

I don't think any other languages have really solved this problem either but it is still an annoying problem.

Re: A different approach to building C++ projects

#47

Post by IshKebab »

saidinesh5 wrote: post #36
matthewaveryusa wrote: post #33

Earlier quoted context omitted.

This is wisdom right here. It's tragedy of the commons. I find that the real problem is no one wants to properly learn how their build system works. I don't care if it's make, cmake or bazel -- whatever it is, you need to _learn_ it. I've worked with folks that have 20 years of experience, fantastic C/C++ developers, that look at a makefile and say "Ugh what is this complicated mess, can you do it in cmake or bazel o…

> I've worked with folks that have 20 years of experience that look at a makefile and say "Ugh what is this complicated mess, can you do it in cmake or bazel or something" This is so true, it happened to me more than once. A couple of projects ago, we had a complicated build process (7-8 manual build steps that depend on files generated from each other before) for an embedded system. I wrote a little makefile deletin…

> each clearly defined step in makefile would turn into multiple unreadable function calls in cmake

Utter nonsense. For most projects CMake is far more readable and maintainable than Makefiles. There's a reason it's the only build system even close to being a de facto standard in the C++ world.

And yes, CMake is totally awful. But it's still slightly better than Make.

(Feel free to post the Makefile!)

Re: A different approach to building C++ projects

#48

Post by db48x »

Has everyone forgotten about deps files? Run gcc -MD and it will create .d files that record the dependencies between your source (and header) files. You can then use an include directive in your Makefile to pull that information in for make to use. There are a couple of variations on the theme; some people recommend putting the .d files alongside your source files, others recommend a specific “deps” directory for them, etc. See the man page for details, with particular reference to options like -M, -MM, -MF, -MD, and -MMD.

Of course, the other alternative is to simply #include _every_ file in your project into a single source file, then compile that. It’ll probably be faster than anything else you do, and eliminates several other foot–guns as well. And it means that your build script can just be a shell script with a single line that runs the compiler on that one file.

But these days I greatly prefer Rust, where building is always just “cargo build”. Doesn’t get much easier than that.

Re: A different approach to building C++ projects

#49

Post by dezgeg »

db48x wrote: post #48

Has everyone forgotten about deps files? Run gcc -MD and it will create .d files that record the dependencies between your source (and header) files. You can then use an include directive in your Makefile to pull that information in for make to use. There are a couple of variations on the theme; some people recommend putting the .d files alongside your source files, others recommend a specific “deps” directory for th…

How does gcc -MD help at all in tracking which .cpp files to link in?

> Of course, the other alternative is to simply #include _every_ file in your project into a single source file, then compile that.

Yeah, no... recompiling the entire project whenever any file is touched is way too slow for any non-trivial project.

Re: A different approach to building C++ projects

#50

Post by kibwen »

IshKebab wrote: post #46
kibwen wrote: post #25

Earlier quoted context omitted.

I'm unsure what this is trying to say. You appear to be in begrudging agreement that Rust is commonly mixed with other languages?

He's saying that Cargo doesn't really help at all with that mixing. Integrating Rust into a multi-language build system is indeed quite a pain. You have a few bad options: * Drive everything with Cargo using `build.rs`. This sort of works but it's pretty horrible. * Give up and just have your main build system run `cargo build`. This is what I normally do but again it's not ideal because it doesn't really integrate p…

> I don't think any other languages have really solved this problem either but it is still an annoying problem.

As you say, this is not a problem with an ideal solution to draw upon. (languages are unavoidably different). From that perspective, I don't see any of these approaches as problems.

If your project is mostly Rust with a little something else sprinkled in, use build.rs ("horrible" is an exaggeration IMO, it's merely not ideal, again, because there exists no ideal).

If your project is mostly something-else with a little Rust sprinkled in, invoke `cargo build` from your build system, and again this is a perfectly adequate solution to a problem with no ideal solutions.

If your project is extra-special, invoke rustc directly, and that's a deliberately supported use case. Hell, I use rustc directly sometimes just because I can.

The bottom line is, Rust provides a best-in-class opinionated build system that is overwhelmingly used by the Rust ecosystem, with best-effort escape hatches for integrating into other projects. To say that Rust cannot "stand the idea that you might want to mix languages", as alleged by the person I originally replied to, is factually incorrect.

Post reply on HN