One more "new" build system after Meson (https://mesonbuild.com/), Scons (https://scons.org/), "Modern" CMake (https://cmake.org/), Waf (https://waf.io/), qmake (http://doc.qt.io/qt-5/qmake-language.html), b2 (https://boostorg.github.io/build/tutorial.html), Jam (https://www.boost.org/doc/libs/1_31_0/tools/build/jam_src/in...), premake (https://premake.github.io/), build2 (https://build2.org/build2-toolchain/doc/build2-toolchain-int...), GYP(https://gyp.gsrc.io/), vcpkg (https://github.com/Microsoft/vcpkg), Bucks (https://buckbuild.com/), Bazel (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...
Now, granted, only(?) seven of these are build systems proper...
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.
- 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.
For anything which requires a "build" (i.e. transpiling typescript or any form of test integration, minification, ...) you are in the land of "arbitrary scripts doing whatever they like" even worse when getting to C++ modules which default to gyp ...
That said, it certainly isn't perfect. Windows support is something that could use some improvements. I've contributed a bit on that front, but since I don't actually use Windows myself it's mostly for the sake of making Bazel usable for more people so I can feel less bad adopting it in FOSS projects. There's a lot of small bits I just don't have time to try and help with right now.
(The usual disclaimer: I work at Google but not on Bazel. At least not during work hours :) )
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.
You could have worded this in a MUCH more pleasant fashion and still gotten your point across. Why did you choose to humiliate?
Could you provide some pointers, ideally a link?
There is some note here
Or more recently with Bazel that do the same but arrives to do it much worst:
Same with Hunter and CMake External:
I have managed an ecosystem of ~250 software for a team in the past.
Software bundling their dependencies are the worst and any package manager will tell you that.
Due to diamond dependency problem, they explode as soon as you try to integrate them into a bigger picture... It is a pure waste of time for every packager.
And I am not even speaking of bug fixes update on dependencies, security update, environment without Internet access or anything like that.... because dependency bundling prevent or make hard all of that.
In all seriousness, the links you provided outline valid (and annoying) issues with package managers, but none of them apply to bake. First of all, bake does not rely on an online package repository. As long as you have access to git, or have local copies of your git repositories, you're good. You'll never lose productivity because your internet connection went down (well- at least not because of bake).
Secondly, the bake package manager does not mandate how you install your projects. This is perhaps the point of greatest confusion. Bake is a package manager for developers, and it provides a nice & seamless workflow for integrating remote git dependencies into your local workflow. How you package and distribute your projects is entirely up to you.
Also, bake has been used to support an ecosystem of 150+ projects, across multiple teams, across multiple organizations, on multiple platforms before it was forked off. In these cases, organizations used their own preferred tools for deployment, but got a good productivity boost from using bake in development.
It does not change anything to all the other problems of bundling dependencies. Including the problems related to diamond dependencies.
> Bake is a package manager for developers, and it provides
a nice & seamless workflow for integrating remote git dependencies into your local workflow
Then just use a developper package manager like Nix, Guix, Spack or EasyBuild that do the staff. Instead of converting every other project to Bake for the sake of it.
As you put so eloquently before, that should not be the prerogative of build systems like bake, but of package managers like apt-get, brew and vcpkg. Bake is blissfully agnostic to those problems (thank god).
One thing that hasn't been discussed so far and I would like to highlight is code that is not distributed through package managers, as so often is the case for commercial closed source code. Bake is a great fit for these use cases, as these projects can simply zip up the bake environment (together with miscellaneous files like HTML, JS and what have you), unzip it on a different machine, and everything just "magically" works.
> Then just use a developper package manager like Nix, Guix, Spack or EasyBuild that do the staff. Instead of converting every other project to Bake for the sake of it.
If you got the impression that I am on a quest to convert every non-bake project to bake, then let me put that concern to rest. I love using bake, it is saving me lots of time and, TBH, I think there are some neat ideas in bake that other people might like, but that's it. After the code is built, it's like every other C/C++ library, and people are free to use whatever build system they feel comfortable with to link with those libraries.
The comic suggests that bake tries to replace all other build systems with a single, unified approach. That is not the case. Bake is a standalone tool, and does not use or depend on other build systems (unless you consider a compiler a build system).
TBF the comic is very appropriate and spot on.