Cmkr – a modern build system based on CMake and TOML | Hacker News Reader

Cmkr – a modern build system based on CMake and TOML

github.com

18 pointsgjvc29 comments

Do we really need to wrap more crap around cmake? It's already wrapping make in an unknowable way, and this layer doesn't help. The challenges when using these things aren't in writing the thing, it's fixing it when it doesn't work, understanding the error messages, etc, etc. Each layer of crap is a huge step backwards. What would you say to the cowboy that will wrap cmkr in another layer of indirection?

Yo dawg, I heard you like generating build scripts, so we put a generator in your generator so you can generate while you generate.

Maybe some day we can come full circle and bring imake back to life and have it generate cmake files.

I think Cmkr fails to state its value proposition by focusing on how it works.

Any system like CMake that wraps boatloads of complexity is going to have unexpected interactions and inscrutable failures.

The question for any developer who doesn't want to become a build system guru is whether they can take a happy path far from any gotcha's.

That's when people start defining conventions to solve classes of problems: follow this template to do X, and you'll be fine.

The value of Cmkr lies in being about to define those conventions and happy paths. I should be able to inspect their templates, and if one fits, I'm good to go.

Even nicer would the ability to retrofit my build to a known-working template.

But Cmkr only presents the "beginners" template repo as an aside, and says nothing about whether these templates are tested for various projects on various systems.

By not explicitly identifying the problem it's trying to solve, Cmkr seems to have bumped up against a solution accidentally, and doesn't give me confidence. I believe that could be easily remedied.

What "boatloads of complexity" does CMake wrap and save me from handling myself?

Turn on all warnings? Yeah, just check if your CC is MSVC or else and set the flag!

Turn on sanitizers? Yeah, just include this 2000 line piece of CMake macro that checks your CC and turns on flags!

Find a package? Yeah, just write a FindFooCMake macro file that spells out the exact files to find in the filesystem and parses a header with more macro magic to determine the version. Maybe we decide to ship this shitty macro file with the default distribution later on and cause more conflicts and distress. By the way, we now have a superior C++ namespace inspired way of defining packages that we mix and match with the old stuff in our default distribution.

Can't you just use pkg-config files like everyone else? Yeah, just make sure to include another 3000 line CMake macro if you specifically want us to use pkg-config.

Cross compile my program for a different architecture? Of course CMake supports that, as long as you write a toolchain file that spells out the exact CC, CXX, sysroot, ... and all other things that could even get a maximally minimal Makefile to trivially cross compile. Make sure to force-overwrite some of the useless autoconfig inspired tests CMake will perform on your toolchain because they are broken with whatever cross compiler you are trying to use.

So while CMake does nothing to help with common things, their "CMakeCache" is the most powerful proof for "nothing is more complicated in programming than caching" the world has ever seen.

I think the point is that every decade or so someone comes out with a new wrapper for the build systems that are wrapping the build systems that are wrapping make. And the developer inevitably makes something that works great for their specific usage of Make/CMake etc in the specific programming niche they occupy. Gradually over the coming decade the build system they created becomes more and more complex as it addresses more and more use cases until it begins to resemble autotools. At that point, someone comes out with a new wrapper and the whole process repeats itself.

At least the find_package documentation is simple:

https://cmake.org/cmake/help/latest/command/find_package.htm...

Sure, there are like 100 pages of useless details in there, but at least they didn’t waste space by explaining what side effects invoking it for a given package will have, or how to find out what package names your system recognizes.

Also, they didn’t complicate stuff by defining any naming conventions around what variables finding a package will set up.

You know, actual important stuff that would be relevant to someone who wanted to use find_package to...find a package.

A build generator for a build generator? Oh boy. This is starting to feel like the JavaScript ecosystem.

I think this is being misunderstood, partially because of the self-claim that this is a build system.

The CMake DSL is utter garbage. From my understanding, this converts TOML that follows the same/similar naming as CMake commands/options to CMake DSL. Allowing for total compatibility with CMake while avoiding the pain of actually interacting directly with a CMakeLists.txt.

Most people agree that CMake is not a good option but the only real option. I'd happily put lipstick on this pig.

There are plenty of options other than cmake. Ideally:

1. read the GNU Make manual 2. Write a tiny build system with Make or use any of the precanned ones. I use this: https://github.com/dkogan/mrbuild/ but there are many others

In any case, learning how to actually use Make is a prerequisite to having an opinion here.

cmake is not just another way to get a Makefile. If you have a cross platform project and want to work in multiple IDEs for specific platforms (xcode/visual studio), cmake or some other build system generator is a huge time saver

That is the one big use case cmake has, yes. But most (all, actually) cmake I see around me is used to just get a Makefile.

3. Read “Recursive make considered harmful”

4. Follow its advice until you hit the end of where it is useful. (i.e., you can no longer count the number of $ escapes in your own code).

Yes. Recursing your Makefiles produces poor results. You know who hasn't read the Make manual and makes recursive Makefiles? The cmake devs.

If you truly need a lot of complexity, you can end up with unreadable Makefiles, as you say. Most projects don't need a lot of build logic, though. I have lots of projects using mrbuild, and their builds are clear and easily maintainable. If you truly need a lot more, then Make might not be the best choice. And you can do much better than cmake

The Make DSL is also utter garbage. As is Autotools. I'm not convinced that wrapping a garbage DSL with another DSL is a value-add when you're building applications.

Looks like it's a declarative CMake so you don't have to interact with the CMake DSL yourself. Which is nice, but I've rarely had a non-sample/toy CMake project where I didn't have to hack something outside of the straightforward steps the docs make it look like you need to do, so my number concern with this is that it's going to end up being a (very) leaky abstraction. How much will cmkr get in the way and make it harder than if you had written out the CMake yourself to begin with? How much of the time will it "just work" vs end up being of little use?

It's great that it's self-bootstrapping, though. I thought they would have you install both this tool and CMake in order to build the project on end-user's machines.

I share your concerns. I mean, I could use a build system that is as powerful and versatile as CMake, but much more declarative and not a horrible inscrutable mess of procedural manipulation of mutable state like CMake is. But that would probably mean replicating, in some way, all the years of work that went into CMake proper and its 3rd-party extensions. Not an easy task.

I want something that is declarative and extensible at its core, and not an after-the-fact bandaid that tries to fix what's broken beyond repair.

Bazel?

So far, the closest buildsystem I've seen to that model is Mozilla's build system (https://firefox-source-docs.mozilla.org/build/buildsystem/bu...), the core of which is a set of python files that basically describe the build graph given the feature context. A simple file might be:

  SOURCES += ['a.cpp', 'b.cpp']
  if CONFIG['OS'] == 'WINNT':
    SOURCES += ['win.cpp']
  elif CONFIG['OS'] == 'OSX':
    SOURCES += ['osx.cpp']
  else:
    SOURCES += ['unix.cpp']

I like that it uses the Python language rather than coming up with its own DSL for handling conditionality or things where you need to do loops, and by splitting up the steps in the way that it does, it keeps the build system fairly declarative. But don't look under the hood, because the things under the hood are fiendishly complex and it's way too complicated to be usable for a simple project.

Interesting - a current (or maybe former) Firefox dev does Half-Life 2 plugin stuff in his spare time and created something similar called ambuild which his projects use.

After working as a C++ developer almost all my career I am moving away from it, so I do not follow it as much. I heard that C++ modules are a step forward and a step back. Don't remember the exact criticism.

Is there a build system where one would point to a one source file and it would find its way around the whole thing? Things it wouldn't be able to deduce would be given as a comment or some preprocessor fluff. Basically implementing module system. Or maybe I did not think it through too much.

Cmkr appears to be a TOML wrapper around CMake. At its current stage of development it only appears to be wrapping the most basic features of CMake (registering binaries and such).

Just my two cents but most of my time spent with build systems isn't on the basics. Most of my time is spent scripting things: probing for dependencies, build hooks, packaging, code signing, and other misc tasks. Right now cmkr doesn't appear to support scripting. I'm unsure a declarative language like TOML will suffice. Might I recommend you research premake which is a build system based on Lua. Lua is a good choice because of its scripting flexibility.

Why dont C++ devs just write their code in CMake? Would probably solve the build system issue.

Or just use Bazel

Don’t you love meta-meta-build systems?

https://xkcd.com/927/

Omg another C++ build system. Who woulda thought we needed another.

It's not like most the popular existing ones are really good (or feel good to use). They mostly have the benefit of momentum.

I almost think there's no way to make a good build system...without making it far harder when you need to do something slightly different. Rust has a simple build system, but it really depends on the package manager, and custom build setup is a build script in Rust...so the build system has to build the build script...

Reply on news.ycombinator.com