A different approach to building C++ projects (opens in new tab)

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 or something" and expect a silver-bullet where-in the makefile build will somehow transform itself into a self-describing intuitive build system by virtue of some sort of hype-osmosis.

The problem is not the build system, it's projects that are seemingly enjoying complexity.

I think there's a good reason for people moving to Rust, aside from the merits of each language, the tooling for using packages is just so much better in Rust.

Every time I've tried to dabble in C++ I've had the same horrible experience.

I end up "Randomly" stabbing at things until it works just well enough to get that particular thing done then dropping it all because it was such a painful experience.

Compared to something like cargo which works really well, C++ and it's build tools just feel flaky.

It may be that I'm just missing a mental model to get to grips with it, but no other major programming language is like that from my experience.

I agree, it’s so horrible. Passing flags to a compiler for some Byzantine rule just to change lord knows what, but it all works now.

What on earth.

I remember back when I was programming in Delphi I could link directly against a .dll, just take a function prototype from the .h file and translate it into a function declaration like this one:

    function I2C_GetNumChannels(out numChannels: Longword): FT_Result; stdcall; external 'libmpsse.dll';

and that was it; but to do this in MSVC you needed not only the .h header and the .dll itself, you also needed that stupid .lib file that had AFAYCT had literally nothing inside it except symbol entries that said "no, load it dynamically from this .dll on startup, please". So it was a rather common source of amusement for Delphi programmers that paradoxically, it was harder to link a program written in C against a DLL written in C than it was to link a program written in Delphi against a DLL written in C.

I wish that would work for all build settings, and be standardized across compilers. Even building complex projects with platform-specific build settings could then be reduced to a simple:

    cc main.c -o bla

Oh, wow, I’ve been thinking for a while about implementing something similar for myself to be used with GCC/clang on Linux.

I suspected that someone might have done it before, but didn’t know of any implementation. I’ll take a closer look at Visual C++ (used it in the last millennium for work) before deciding how mine should work.

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

The problem I've found is that it gives you the name…but not the path. I've ended up seeking ways to turn it off every time I've run into it.

FD: CMake developer

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.

One big lesson that newer languages like go and rust seemed to have learned is that the tooling, building and dependency management need to be dictated as part of the language ecosystem. Dealing with tons of other C++ projects written by other people (even in the same company) - how to specify dependencies, where their build artifacts can be found, etc - is a HUGE pain in the ass and consumer of my time.

Dependencies fit into this model, too. Presumably the dependencies build wherever they came from. Do that, package the output, and put it somewhere your project can use it in the suggested manner.

The point is that the tool is opinionated and demands that this be the case for projects that work with it. Not that the author believes all .cc / .h files work that way.

Your use case would be served by C23's #embed [1]. The same thing has been proposed for C++ but repeatedly kicked down the road because the standardisation committee wanted to make it more general even though no one had any demand for that so they didn't know what it would look like. (C++ standardisation in a nutshell.)

[1] https://thephd.dev/finally-embed-in-c23

So, you do things in a way that would not support this approach. She’s not saying “this is always how it’s done”, she’s explaining what practices you would need to commit to in order for her approach to be viable:

> “If you want something like this to work, you have to commit to a certain amount of consistency in your code base. You might have to throw out a few really nasty hacks that you've done in the past. It's entirely likely that most people are fully unwilling or unable to do this, and so they will continue to suffer. That's on them.”

I started as a python programmer and was very used to package managers. I believed in them, I championed them. When I switched to C++ for work I was very disheartened that there wasn't a standard.

Conan obviously has promise, I haven't spent much time with it, most of my experience with C++ package managers is with nuget and vcpkg. However, my attitude toward package managers is changing.

I increasingly like _not_ using package managers because it makes me (and my company) way way way less likely to bloat our software with unnecessary third party dependencies.

I wrote this in another thread: I never believed you should write something yourself if you can find a package for it. My boss told me I should write it all myself, I could probably write it to be faster. I encountered a case where I needed to compare version numbers in python. For the heck of it I wrote the simplest, quickest, most naive solution I could come up with and then timed it against the most recommended version comparison package in python. I blew it away by 20x throughput.

I don't believe in package managers anymore. Obviously I'll keep using pip and sqlalchemy in Python, but I'll happily spend the 20-30 minutes it takes adding something like nlohmann-json or md4c to my project over worrying about maintaining a package manager for c++ these days. Precisely because it makes me think twice about adding another dependency.

Yes, this. I've been reading many comments here about problems with different dependencies and their own unique build system and kept thinking "Conan would fix that". I'm surprised that it's still so unknown in the C++ world.

I prefer the equation, :)

vcpkg/NuGET + (any build system) = problem solved