C and C++ is known for its abysmal dependency and build system situation. For historic reasons a build system has not been standardized thus low level build tools such as make and ninja as well high-level build tool generators such as Autotools, CMake, meson and entire build frameworks like bazel have come and gone throughout the years.

A lesser known build generator is coremake. And lets be honest: it is a horrible, underdocumented piece of shit written in hard-to-follow spaghetti C. I would not even call it a build system generator it is more a static generator tool that reads its own undocumented domain-specific language (which is actually not that bad because like meson it can only declare dependencies) written in .proj files and a so-called “platform” file that, amusingly, ends in .build. That platform file is does not just specify a certain tool chain and maybe CFLAGS but is a hodge podge of that and instructions how to generate output. As you can tell from the official repo, insane people have done the insane and written generator code for Android, make, Visual Studio and whatnot.

Since, the make backend defaults to recursive Makefiles (booo), I was tempted to add one more to the whatnots and that is ninja. Some may know it as the default backend of meson and an optional backend of CMake. Anyhow, on a scale of 1 (make) to 10 (bazel) in terms of stuff, it ranges somewhere between 0.01 and 0.02 thus all logic must come from a meta build system. And to spare you the work of figuring this out, here is something for the second advent which allows you doing this

$ coremake ninja-clang-linux_86_64
$ ninja
$ ninja -t compdb > compile_commands.json

Adding basic ninja support to coremake was a small adventure. Although ninja’s description language is super easy to follow, figuring out coremake’s quirks concerning scoping and path makes you want to puke and I am certain I have only scratched 5% of the disgusting surface.