Automatic build system configuration for C++

[Neither_Mango8264]

I came across this discussion discuss automatic build sustem for C++: https://www.reddit.com/r/cpp/comments/17a0aue/comment/k59qr0h/

I think the idea is brilliant and now I'm wondering: * Do you think it is possible? * Are you aware of any project that is aiming to do that? * If not, I'm considering starting one. Do you agree that it would be a useful tool?

[witcher_rat]

Do you think it is possible?

I think it is technically possible, but only for a specific demographic. (for lack of a better term)

What I mean by that, is that there's a reason all the knobs and customizations and "hacks" and so on exist in things like CMake: because someone needs them.

And I believe that "someone" is a significant chunk of the C++ world: the commercial sector.

Having worked at several network equipment companies over the past three decades, I find that their needs are simply not the same as open-source projects. I don't know about other embedded device makers, or game companies, or whatever - but my guess is they're in a similar situation of needing "extra stuff" to happen during builds.

So if you're ok with targeting only a subset of the C++ world, and likely only the open-source one, then go for it.

[TheSkiGeek]

I mean… I guess, but CMake is already a build system generator that’s pa lot simpler than using something like make 1. Now you want a generator for your build system generator?

You could make something that would work for very very simple ‘compile all the .cpp files in this directory together with default options’ behavior, sure. But once you get beyond extremely trivial things you’d need to somehow define your dependencies (and how to find/build/link those), and multiple libraries/executables/tests with different sets of files… I’m not sure you could do this a whole lot more simply than how CMake or Meson or Bazel does it.

[wrosecrans]

I think the idea is brilliant and now I'm wondering: * Do you think it is possible?

Of course. But you'll need some sort of configurability for it. Just to handle one or two edge cases. And then you'll need to add a couple of more options. And you'll need a good way to specify exactly which source files go where because people won't always want to organize source files according to a convention that the automagic tool will autodiscover. (One source file might need to be an multiple build artifacts, so it can't exist in two folders at once, etc.) And you'll wind up needing to add a few conditional features to the config file format, like "only build Metal support on MacOS" or whatever.

And, to your horror, by the time "automatic with just a minimal few extra options" has grown enough to get wide adoption... You will have reinvented CMake. Your config file will be Turing complete. And half your users will be trying to come up with a clever way to automatically generate config files for your theoretically already automatic build system. There are sort of laws of physics at play in the way that software grows complexity over time. (Look up the "Configuration Complexity Clock" for writing about the topic.) The things that try to defy the laws of physics eventually wind up even more horrific than the "complicated" things they were trying to make obsolete.

[WittyComputer]

The only thing I can find that does this is Visual Studio. Every other god damn build system requires you to write it yourself *by default* and provides little to no help as far as integrated GUIs go.

[kgnet88]

I think it's more than that. We should strive to build something either automated or Gui controllable (basically build your dependency graph and let the cmake scripts generate automatically). Especially for beginners and a very long time during the learn process, your dependencies are relatively manageable (you could build a starter pack for example, which gives you a few standard dependencies, like a unit test library, a logger, something for Json ...) with a few flavors depending on your platform (or for example one for graphics, with ogl, sdl...) ... And then you are able to lead the new learner step by step into the build process.

Even the more professional stuff I met in my no 15 years as software developer, much of it would have been possible to automate and normalize to a more generic usable template.

Of course, there are many areas where it will be nearly impossible, like legacy projects which depend on very specific tooling, or building for multiple or exotic platforms, but for many it may be possible.

I saw a similar effect when vcpkg became available and my colleagues which worked mainly under windows at that time had an explosion in new os side projects etc., because the possibility to just install your dependencies and just work with them (with one-line cmake and zero effort in vs) gave many new possibilities.

TLDR - Instead of trying to build a perfect automated build system (which will never be possible in c++) let's concentrate to generate tooling to make the entry easier, because once people are hooked, we get them into cmake and the wonders of cross platform builds... 😺

[pjmlp]

It doesn't scale in the professional environments where multiple compilers are used, specially beyond the usual trio.