Show HN: Bake – A modular build system and package manager for C/C++ (opens in new tab)

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

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

Thanks for the comprehensive list of alternatives, there's some that I wasn't even aware of ;-) A few observations:

- Bake has been used across platforms for large projects and its declarative approach held up pretty well. Note that being declarative does not mean a configuration cannot contain conditional attributes (which bake supports). You need conditionals for things to work properly on different platforms, like documented here: https://github.com/SanderMertens/bake#can-i-link-with-non-ba...

- I share the frustration, but I do not share your conclusion. Bake takes a refreshing approach to package management in that it doesn't try to do too much, which is perhaps what turned you off in other projects. It doesn't even compete with package managers like brew or vcpkg (which is not a build system, you might want to correct that). I would go into more detail, but then again I've already done so in a few comments, and the README is pretty comprehensive in explaining how it works.

- I did not invent my own syntax, the configuration is written plain JSON. Whether this was a good or bad decision we'll have to see, the jury is still out on that. NPM seems to do alright though.

So far, the people that have actually used bake have been unanimously positive. I can confidently state that the learning curve of bake is much lower than a tool like CMake or premake (which I like), let alone make or autotools. Based on the feedback of Bake's users I decided to spin off the project, as I figured others could benefit from it too. So yes, it is yet another tool, but IMHO there's little harm in that.

Like... Make? I’ve been slowly converting the Jr devs to Make. You know the best part about Make? The documentation provided by GNU: https://www.gnu.org/software/make/manual/make.html.

I'm still sticking with CMake.

Autotools on Windows is an absolute nightmare and none of the other build systems have nearly as much support as CMake when it comes to integration with various tooling (as in tools which understand CMake).

I like gn, but it has the annoying problem of needing anything in-tree to be converted to gn.

Is it really necessary to be so mean and passive-aggressive?

You could have worded this in a MUCH more pleasant fashion and still gotten your point across. Why did you choose to humiliate?

> for reasons discussed 20 times

Could you provide some pointers, ideally a link?

vcpkg as another alternative package manager

The worst part is that a large portion of the push back against improving the tax system here in the US is all the tax software companies. Intuit (and H&R Block) spend millions every year lobbying against tax code simplifications or at least simplifying how you interact with the IRS.

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.

Thanks for bringing that up, I agree that the example is quite trivial, though I think it's at least a fair comparison when it comes to general complexity of two simple projects.

Regarding find_package; it does sound similar to bake's discovery. There is a not insignificant difference though between how both work in practice. Without going into too much depth, CMake attempts to find a package by looking at (a potentially large number of) system paths. It attempts to adhere as well as possible to the conventions of that platform.

On the other hand, bake recursively searches for projects from where it is being invoked, in addition to looking in a "bake environment". The latter is a self-contained, fixed-format directory structure that contains all projects built with bake. A bake environment is by default stored in a user's $HOME folder, but can be configured to (for example) /opt. Bake environments can be easily moved to different directories and even machines.

There is nothing inherently right or wrong with either approach, but they are certainly different. Bake's approach was designed to accommodate a scenario where a developer is working on a large number of (potentially shared) projects at the same time, and for that it works really well.

Bake has been used for well over 4 years (in various iterations) in big and small organizations. It held up pretty well for large-scale projects, though I should mention that, as with any tool, it can be misused. Big organizations in particular will have to establish conventions and guidelines around using bake, just as they would have to do with any other approach.

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.

Yes, other formats were considered. There is some irony here, as I've been a vocal critic of JSON in the past (https://www.linkedin.com/pulse/may-time-stop-using-json-sand...). I ultimately went with JSON because it's ubiquitous, it has been used for similar purposes (NPM) and it has a great parser (parson) that was easy to embed without adding more dependencies to bake.

Time will tell whether JSON scales, but so far it has held up pretty well. Bake has been used by small & big organizations, while building large numbers of packages simultaneously (150+). The most complex bake project.json I've seen was still far less verbose than the average CMake file (using CMake as a benchmark since it has been widely adopted).

Toml would be the best choice IMO

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.

Yes, that is correct. Bake can find dependencies regardless of where the dependency's source code is. You also don't need to first install your project before it can be used as a dependency, building is enough.

A big difference with CMake is that bake stores package binaries, include files and metadata in a $HOME/bake directory. It won't actually install anything to /usr/local (or equivalent), unless you explicitly tell it to. Users typically first build everything to their $HOME/bake folder, and then when they want to make it available for all users, copy the contents of that folder to /opt when distributing the project.

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.

No, they seem unrelated.

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.

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

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...

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.

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 ...