[HN Gopher] Cmkr - a modern build system based on CMake and TOML
___________________________________________________________________
Cmkr - a modern build system based on CMake and TOML
Author : gjvc
Score : 14 points
Date : 2024-05-06 12:20 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ComputerGuru wrote:
| 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.
| tempodox wrote:
| 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.
| Nuzzerino wrote:
| Bazel?
| jcranmer wrote:
| 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.
| jamesfinlayson wrote:
| 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.
| dima55 wrote:
| 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?
| wheybags wrote:
| Yo dawg, I heard you like generating build scripts, so we put a
| generator in your generator so you can generate while you
| generate.
| eej71 wrote:
| Maybe some day we can come full circle and bring imake back to
| life and have it generate cmake files.
| arberx wrote:
| Omg another C++ build system. Who woulda thought we needed
| another.
| izoow wrote:
| A build generator for a build generator? Oh boy. This is starting
| to feel like the JavaScript ecosystem.
| arberx wrote:
| Why dont C++ devs just write their code in CMake? Would probably
| solve the build system issue.
| Nuzzerino wrote:
| Or just use Bazel
| w10-1 wrote:
| 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.
| stefan_ wrote:
| 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.
| throwway120385 wrote:
| 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.
| bangaladore wrote:
| 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.
| dima55 wrote:
| 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.
| throwway120385 wrote:
| 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.
| hawski wrote:
| 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.
___________________________________________________________________
(page generated 2024-05-08 23:01 UTC)