There are some other distro specific build systems missing. So I wouldn't think much of it. But here would be my point for 'Nix': QA doesn't tested for Cross-compiling so it doesn't work while it should be supported in principle.
You include "Yocto" (which someone already pointed out should be bitbake) but not kconfig, which is used by Linux, Buildroot, Busybox, uClibc-ng and a couple more projects).
Nice list! CMake is missing a few dozen entries though!
"Stringly typed" - even lists are just semicolon-separated strings.
Insane quoting rules. I recently tried to work out exactly how the argument parsing works and the source code has undocumented behaviour. It's ridiculous.
Accessing undeclared variables works fine. They're just empty. Good luck tracking down silently ignored typos!
waf continues to be the underappreciated gem in this space: high level build language supporting many languages and tools, cross platform, implemented and extensible in Python, nothing to install (except Python), and fast.
It is quite fast and Python is a nice language for specifying the build, but I found waf to be difficult to extend.
I had some tests that needed a binary file. That binary file was generated from a text file by a utility program. That utility program had to be built from source.
After a week of trying to get that correctly specified, I gave up. I thought I'd found the right way of doing it several times, but each time I discovered the dependency chain was broken in some way. I looked into how official modules that dealt with generated files were implemented, but I found them to be surprisingly complex.
By comparison, it was only mildly annoying to do that sort of thing in CMake (the build system I moved to after a year or two with waf). The relative simplicity of CMake was what convinced me to switch.
That being said, it's been several years since I last used waf. It may have improved during that time.
I have found the learning curve to be very steep. Extension points are several, subtle, and powerful, leveraging heavily not only normal OOP but also python meta programming. It is not out of the question go beyond all that and monkey patch some core class; I’ve seen this recommended by maintainers in some circumstances.
The docs are up front that waf is not a build system but a build system toolkit. For example, there is a demo that uses makefiles as the build language and runs them in waf. Another demo requires no build file but just finds the source files and builds them. But I have yet to see any external project released that says, “This is a build system... built on the waf build system toolkit,” like the Software Construction Toolkit was built on scons. Perhaps the toolkit is so close to being a build system that people just use it as is and require only small customizations, which are kept in their projects.
Wow. How is a system not supporting the most widespread desktop platform on the planet claiming to be cross-platform?
Having said that, there might be a way. From their FAQ:
> It might well be possible to make it work using Cygwin or MinGW / MSYS, or the recent Ubuntu on Windows development though. We aren't doing this work ourselves because we don't have any Windows machines, but we're happy to accept PRs in that direction.
Not sure I want to use a platform which the dev team can't test (and there are other alternatives), but it might work after all.
A side remark, the link posted below in this thread contains an awesome "awesome" list. For those interested, here is a (truly) awesome list of dataset resources: https://github.com/awesomedata/awesome-public-datasets.
Cross-platform just means more than one platform. Nothing more. There's segments of developer market that don't need Windows support. Those targeting Linux/BSD, Mac desktops + Linux-based backends (i.e. cloud), multiple UNIXen (eg Linux + Solaris), embedded developed on Linux boxes, etc.
I encourage Windows versions of cross-platform apps wherever the app could justify it due to all the developers and tooling on Windows. Yet, non-Windows apps can be cross-platform.
If someone says cross platform and it supports Linux, Mac, and BSDs, that is good enough for me. I have not done any development work on Windows in my entire life just like I have not done any development work on my Android phone.
I for one do not expect windows support in a build system. Recently, someone said adding support for space in the filename in make adds a complexity we can avoid. I'd argue adding Windows support adds a complexity we can avoid. I'd rather they didn't support Windows. I say we can revisit this issue if enough people still use Windows on the server ten years from now.
