A different approach to building C++ projects

I wish we had a culture that expected every new C/C++ build system to handle a non-trivial project like Boost or Qt (and their dependencies, like ICU and OpenSSL) before it being pitched as the new best thing. It's trivial to make a build system that elegantly handles your own toy projects that follow your preferred style and structure. But the real world of C/C++ is a harsh place with a lot of variability.

This is sort of unrelated, but that reminds me that one of my biggest issues with learning C++ was how I was expected to deal with libraries (particularly on Linux, where conventions will even differ between distros) and building the project. Most guides or what have you sort of teach you how to compile a file or two, but you quickly run into issues that are difficult to solve for a complete beginner without a direct source of feedback.

One of the nice things that Visual C++ has is<p><pre><code> #pragma comment(lib, &quot;xxx.lib&quot;) </code></pre> 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.<p>I have found myself wishing that GCC would also get something like this.

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.<p>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.<p>But these days I greatly prefer Rust, where building is always just “cargo build”. Doesn’t get much easier than that.

This sounds like it would be fine for code that you write yourself. But if you&#x27;re only compiling code you wrote then C++ build systems are pretty trivial. The hard bit is dependencies.

<i>One .cc&#x2F;.h pair, one object</i><p>Not always the case; I have a project with<p><pre><code> default.o: default.yaml $(LD) -r -b binary -o default.o default.yaml </code></pre> and a default.h containing<p><pre><code> extern const char _binary_default_yaml_start[]; extern const char _binary_default_yaml_end[]; #define PARAM_YAML _binary_default_yaml_start #define PARAM_YAML_LEN (_binary_default_yaml_end - _binary_default_yaml_start) </code></pre> this used in the main code as<p><pre><code> fwrite(PARAM_YAML, 1, PARAM_YAML_LEN, stdout); </code></pre> printing the contents of the yaml file to stdout.

This is sort of the principle of the &quot;bpt&quot; build tool I think from &quot;vector-of-bool&quot;<p><a href="https:&#x2F;&#x2F;bpt.pizza&#x2F;" rel="nofollow">https:&#x2F;&#x2F;bpt.pizza&#x2F;</a>

<i>&gt; If you want something like this to work, you have to commit to a certain amount of consistency in your code base.</i><p>That goes for almost everything, in developing ship code.<p>Today, I am in the initial stages of rewriting an app with a codebase that has “accreted” over two years.<p>It’s kind of a mess (my mess, to be clear).<p>I’ll be adding a great deal of rigor to the new code.<p>I think it will come out great, but I have my work cut out for me.

Conan + (any build system) = problem solved<p>Conan has a learning curve, but it’s totally worth it. Anyone making their own build system should get some experience with a state of the art package manager before writing a single line of code, because chances are that it already solves whatever problem is motivating you.

I have been managing all my existing and new projects with nix for a few years and never look back. Guaranteed to build and run on all my machines.<p>nix flake new --template &quot;github:nixvital&#x2F;flake-templates#cpp-starter-kit&quot; my-project<p>will create a skeleton for my new C++ projects.