- 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.
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.
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.
NPM isn't really json if you leave the easy JavaScript only place.
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 ...
You are doing them a disservice. At least for cross platform C++ the best thing to use right now is CMake, followed by Bazel and gn (what chrome uses). The reason CMake is a good idea is because a large number of C++ projects support it and it has decent integration with XCode, Visual Studio (Code) and pretty much everything else as well. Using ninja gives you decent speed.
CMake is painful to use for so many common things I find it hard to believe it's achieved the popularity it has. For instance, given the focus on out-of-source builds, the -H and -B options remain undocumented for vague reasons. The community has also sworn off clean builds for some reason. The most baffling part is how anemic the command line interface is compared to the scripting language. For a tool targeting the command line aware C/C++ communities, it's far too common to rewrite build scripts with awk/sed/perl because the command line doesn't have the options you need.
I think Bazel is a really cool option. It really does deliver on the 'fast, correct' promise strongly.
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 :) )
Yeah, make can be useful tool but it solves different set of problems than Autotools or CMake. Definitely not a fan of either of them but currently CMake seems to be the least bad choice for cross-platform development. Like the C++ language itself ;-)
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.
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.
> 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).
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.
> It does not change anything to all the other problems of bundling dependencies. Including the problems related to diamond dependencies.
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).
I was trying to remember where I'd last seen this comic and now I think that reddit is indeed exactly where I saw it about a week ago. Coincidence, same project thread.
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...