
Show HN: Bake – A modular build system and package manager for C/C++ - ajmmertens
https://www.github.com/SanderMertens/bake
======
adev_
Cool.

One more "new" build system after Meson
([https://mesonbuild.com/](https://mesonbuild.com/)), Scons
([https://scons.org/](https://scons.org/)), "Modern" CMake
([https://cmake.org/](https://cmake.org/)), Waf
([https://waf.io/](https://waf.io/)), qmake ([http://doc.qt.io/qt-5/qmake-
language.html](http://doc.qt.io/qt-5/qmake-language.html)), b2
([https://boostorg.github.io/build/tutorial.html](https://boostorg.github.io/build/tutorial.html)),
Jam
([https://www.boost.org/doc/libs/1_31_0/tools/build/jam_src/in...](https://www.boost.org/doc/libs/1_31_0/tools/build/jam_src/index.html)),
premake ([https://premake.github.io/](https://premake.github.io/)), build2
([https://build2.org/build2-toolchain/doc/build2-toolchain-
int...](https://build2.org/build2-toolchain/doc/build2-toolchain-
intro.xhtml#preface)), GYP([https://gyp.gsrc.io/](https://gyp.gsrc.io/)),
vcpkg
([https://github.com/Microsoft/vcpkg](https://github.com/Microsoft/vcpkg)),
Bucks ([https://buckbuild.com/](https://buckbuild.com/)), Bazel
([https://github.com/bazelbuild](https://github.com/bazelbuild)) and
autotools.

It is true that one more was really needed.

One more that has the genetic disease of :

\- Trying of being "purely declarative", a thing that at least 4 build system
already tried and failed as soon as portability and configuration kicks into
the picture.

\- Try to merge the concept of build system and package manager: A terrible
idea for anything touching C/C++ for reasons discussed 20 times already.

\- Use its own syntax and config, because that is really what every developer
want to do: Learn how to use a build system zoo for every component they want
to use.

Well done guys.

Edit: I forgot some...

~~~
naniwaduni
Are we making lists? Can we talk about bake
([https://github.com/esrlabs/bake](https://github.com/esrlabs/bake)), bake
([https://github.com/linuxrocks123/bake](https://github.com/linuxrocks123/bake)),
bake
([https://hackage.haskell.org/package/bake](https://hackage.haskell.org/package/bake)),
Bake ([https://www.openhub.net/p/bake-build](https://www.openhub.net/p/bake-
build)), BAKE ([https://www.nsnam.org/docs/bake/tutorial/html/bake-
over.html](https://www.nsnam.org/docs/bake/tutorial/html/bake-over.html)),
Bakefile ([https://bakefile.org/](https://bakefile.org/)), BitBake
([https://www.yoctoproject.org/software-
item/bitbake/](https://www.yoctoproject.org/software-item/bitbake/)), and cake
bake
([https://book.cakephp.org/3.0/en/bake/usage.html](https://book.cakephp.org/3.0/en/bake/usage.html))?

Now, granted, only(?) seven of these are build systems proper...

~~~
ajmmertens
Thanks for highlighting this- yes, there are quite a few other projects named
bake. The internet is a big place, and while that means that it's almost
impossible to come up with a name that's not already in use, the likelihood of
running into each other is also small. In other words: I don't see this as a
big problem unless one of the "bakes" becomes really big (like CMake big).

So what is the chance of this happening? Lets look at the list you provided:

\- some aren't (C/C++) buildsystems (hackage::bake, bitbake, cake bake).

\- some projects are dead (linuxrocks123/bake, openhub.net/bake-build,
nsnam.org/bake)

\- some projects are almost dead (esrlabs/bake)

That leaves one active project, which is Bakefile, which is not a build system
but a makefile generator akin to premake. Bakefile (not bake) has a very
different front-end (a bkl file) and different intent, so the potential for
confusion is not big. IMO the internet is big enough for two _different_
projects with a _similar_ name :-)

Worst case the similarity in names makes it harder for me to get traction, but
that's ok really. For me bake is a means to an end, and by no means the most
important thing I'm working on. Would I enjoy it if people adopt it? Sure. But
it's not the end of the world if that doesn't happen.

------
saagarjha
Interesting README:

> The Dutch IRS has a catchy slogan, which goes like this: "Leuker kunnen we
> 't niet maken, wel makkelijker". Roughly translated, this means: "We can't
> make it more fun, but we can make it easier".

If only filing taxes in the U.S. was like this…

> Bake does not collect any information when you clone, build or publish
> projects.

It's sad that this needs to be said.

~~~
cbcoutinho
I moved to the Netherlands five years ago from the US - dealing with the tax
agency here is such a breeze compared to the IRS.

~~~
kartikkumar
Having lived in a bunch of countries over the past decade, it's only when I
moved back home to NL that I fully appreciated how easy things are.

Firstly, digital filing is the norm and for "simple" returns, just works.

Secondly, if you ever have a question, you can just call the tax authority on
their free phone number, and pretty much ask them anything related to
individual or business tax returns.

~~~
mattkrause
I once had to call the IRS for something and it also “worked”. The wait time
was pretty reasonable (5 min or so), the person I spoke with was polite,
knowledgeable, and actually resolved the problem on the first try.

It was heads and shoulders above most interactions I’ve had with with ISPs,
big banks, and the like, where you get transferred around between departments
that don’t seem particularly interested in helping you out....

------
humanrebar
The comparison to CMake isn't apt:

[https://github.com/SanderMertens/bake/blob/master/README.md#...](https://github.com/SanderMertens/bake/blob/master/README.md#how-
does-bake-compare-to-cmake)

CMake projects allow proper recursive inclusion, so this would be sufficient
to include 'bar' and link against it:

    
    
        add_subdirectory(bar)
        target_link_libraries(Foo bar)
    

...this only assumes that somewhere in the 'bar' directory, 'add_library(bar
.....)' is called.

Alternately, one can (and often does) use a 'find_package(bar)' call instead
of 'add_subdirectory' to pull in a library installed on the system somewhere.

The main difference seems to be that bake is configured with a particular json
schema while CMake is configured with scripts written in the CMake language.

I'm skeptical that the json approach stays as same as advertised once large
and distributed organizations use the tool seriously. At scale, I expect a
bake json to resemble a maven xml, albeit in json.

I'll also note that bake doesn't seem to support a distinct test phase, which
will likely cause issues in large organizations; they would need a separate
test configuration system on the side somehow.

~~~
weberc2
Declarative file formats mostly seem to work fine for every other language.
The only thing that I can think of that is unique to C++ is that the ecosystem
is full of projects which use cobbled-together build scripts in imperative
languages, which means your project may need to interface with these scripts;
however, a package manager means that only the package maintainer needs to
worry about these scripts; not every project that depends on them, so the
declarative approach should work just fine as with other languages.

~~~
humanrebar
Yeah. You hit the nail on the head. Lacking a standard package manager, no
module system, need for incremental compilation, and semantically significant
preprocessor symbols (among other things) make C and C++ require a lot of
power tools for building at all correctly.

Even relatively cleaner languages like Java need fairly involved declarative
config files like pom.xml.

> ...only the package maintainer needs to worry about these scripts...

Package maintenance is only one part of the puzzle. There are still analysis,
code transformation, documentation generation, and other kinds of automation.

There's also packaging for different ecosystems. Each package manager, Conan,
monorepo systems, and each company specific system out there (maybe the most
common concern).

A language like python already has standard languages and formats to both keep
the number of integration points small and to keep the remaining ones
supported.

In other words, I expect project.json to mention Doxygen and clang-tidy and
DPKG at some point. Otherwise there will need to be pretty flexible ways to
expose bake-deduced data to those tools.

~~~
ajmmertens
Funny you mentioned that- before it was forked bake had doxygen & test
framework integration. I'm working on porting the test/doxygen drivers as we
speak.

~~~
humanrebar
I suspect you'll need to iterate or offer a variety of drivers in that space.
Doxygen has a lot of configuration needed, often including generation of a
suitable Doxyfile.

Testing is often just as complicated as the build. There can be interconnected
packaging and runtime requirements for integration tests, for instance.

You could probably support portable, package-time unit tests without a lot of
work though.

------
kstenerud
[https://www.github.com/SanderMertens/bake](https://www.github.com/SanderMertens/bake)
is a fork of
[https://github.com/cortoproject/bake..](https://github.com/cortoproject/bake..).
Is there any reason why the title link doesn't go to the original?

~~~
ricardobeat
Around halfway through the README it explains its origins in the Corto
framework and how it has been extracted as an independent project.

------
mehrdadn
Is this related to Bakefiles? There's already something with that name. [1]

[1] [https://bakefile.org/](https://bakefile.org/)

~~~
naniwaduni
It's like the second name everyone comes up with. There are _at least_ five
build systems (or adjacent) named bake. Probably a few orders of magnitude
more.

------
Ericson2314
My two favorites parts:

\- always cross: native builds are just build=host builds.

\- preprocesses as separate step efore building

------
radarsat1
Cue the pull requests adding yet another build system to my projects..

~~~
ajmmertens
No need, bake can link with your projects like it can link with any other
C/C++ library: [https://github.com/SanderMertens/bake#can-i-link-with-non-
ba...](https://github.com/SanderMertens/bake#can-i-link-with-non-bake-
libraries)

------
bake
I'm honored

~~~
j1elo
So what I understood from the readme is that all dependencies would also need
to be configured around Bake, is that correct? I guess this will be the main
_chicken and egg_ problem, as with other build tools, given the variety of
tools that exist and are used across different libraries. Although I've found
that autotools tends to be a common denominator in most of the ones I've had
to work with...

A minor detail: the table under _Template Functions_ is not properly formatted
and Github doesn't render it as a table.

~~~
ajmmertens
Thanks for finding the formatting issue, fixed it!

You don't need to specify all dependencies "the bake way". If you want to link
with a non-bake C library (like pthread or dl), you can configure it like
shown here:

[https://github.com/SanderMertens/bake#can-i-link-with-non-
ba...](https://github.com/SanderMertens/bake#can-i-link-with-non-bake-
libraries)

It is also possible to wrap existing libraries in bake projects. This section
of the README describes how:

[https://github.com/SanderMertens/bake/blob/master/README.md#...](https://github.com/SanderMertens/bake/blob/master/README.md#integrating-
non-bake-projects)

~~~
j1elo
Oh sorry, I hadn't read the whole document. Thanks for the link, now I'll
finish reading it!

------
kartikkumar
Interesting.

I've been messing for a while with my own boilerplate C++ project [0], since I
got sick of having to recreate the CMake set up for every app I created. It's
taken a lot of CMake magic to get it working and I'm still not totally happy
with the config using ExternalProject_add to automagically deal with
dependencies that aren't present.

I've been evaluating Hunter [1] and wondering whether to step over.

If I understand correctly, the big advantage of Bake is that it completely
replaces CMake for dependency management (at least that's what I take away
from the readme)?

[0]
[https://github.com/kartikkumar/cppbase](https://github.com/kartikkumar/cppbase)

[1] [https://github.com/ruslo/hunter](https://github.com/ruslo/hunter)

~~~
humanrebar
Avoid ExternalProject_Add. You're better off using 'find_package',
'add_subdirectory', 'pkg_check_modules', or Conan depending on where your
dependency comes from.

In my opinion, CMake is best as a (meta)build system, leaving packaging
details to a different layer.

~~~
kartikkumar
I use ExternalProject_Add of building external dependencies from source, like
this:
[https://github.com/kartikkumar/cppbase/blob/master/Dependenc...](https://github.com/kartikkumar/cppbase/blob/master/Dependencies.cmake)

------
ricardobeat
Was YAML, CSON or some other format considered for config? JSON is not exactly
human-friendly.

~~~
richardwhiuk
Toml would be the best choice IMO

~~~
crdoconnor
TOML is syntactically noisy and about 50% more verbose.

~~~
cyphar
I'm not sure how

    
    
        [general]
        foo = bar
    

is 50% more verbose than

    
    
        { "general": { "foo": "bar" } }
    

But also it's significantly more human-readable (and critically, it's _much
more human-writable_ ).

~~~
crdoconnor
It starts to get more verbose when you have more keys and deeper indentation
since the whole hierarchy is repeated for each key e.g. [general.foo.bar.bar].

JSON wasn't intended for maximal human readability/writability like CSON/YAML
were. It was intended first and foremost as a simple data transmission format.

~~~
richardwhiuk
Large hierarchies are always difficult in plain text formats. I'd argue if you
need the user programming the config to understand a large hierarchy then
you've already got a problem.

~~~
crdoconnor
By large I mean two/three levels and above. Nothing's perfect but YAML does
that fairly well (e.g. ansible playbooks)

TOML handles anything three levels or above in a less readable way than
indented JSON (which doesn't even prioritize readability).

It looks find provided you're only dealing with tiny ultra simple config
files.

~~~
richardwhiuk

       [foo.blah.bee]
       hi = 4
    

seems readable enough.

------
ape4
JSON seems to verbose for this

~~~
mistrial9
the criticism above was that _make_ alone is not machine-understandable,
therefore an IDE or other toolchain tooling parts cannot assist. _JSON_ output
(and the assumed contents of the JSON structures) enable another computer
program to understand something about the build, and also is not terrible for
humans to read.

------
kstenerud
How do you run unit tests in a bake project?

~~~
ajmmertens
I am currently working to reintegrate a feature in bake (from before the fork)
that will allow you to run unit tests on discovered projects. Stay tuned ...

