BUSY VS GnTools

CMake - as autotools - is a meta build system; it e.g. generates make files, which are essentially scripts. Also CMake itself is essentially a VM with a scripting language. Both CMake and Make are Turing complete (and dynamically typed, as mentioned). And yes, not all build systems are the same; e.g. https://github.com/rochus-keller/BUSY has a statically typed specification language and intentionally avoids a Turing complete language.

> Have you coded the lexer/parser from scratch

Yes. Here is the lexer: https://github.com/rochus-keller/BUSY/blob/main/bslex.c

and here is the parser: https://github.com/rochus-keller/BUSY/blob/main/bsparser.c

and here is the specification: http://software.rochus-keller.ch/busy_spec.html

I also developed and checked the EBNF in parallel using my EbnfStudio tool; this tool could also generate a parser, but since I'm using much of the Lua VM infrastructure a manual parser implementation was more straight-forward .

If you haven't seen it: https://github.com/rochus-keller/BUSY

> BUSY is a lean, statically typed, cross-platform, easily bootstrappable build system for GCC, CLANG and MSVC inspired by Google GN

It uses lua and config files that are mostly directories and filenames.

> Instead of qmake the BUSY build system (see https://github.com/rochus-keller/BUSY) is used

It must be a rite of passage to make(!) one's own build system, damn

Thanks. It's far from perfect, but at least it made it possible to build the Oberon IDE with toolchain and LeanQt all in one batch with no other requirements than a C89 and C++98 compiler.

> Even with big builds we don't have to much variables hammering

Have e.g. a look at the Chromium or Dart VM build; it's huge and very complex; understanding the build system given that most of the relevant information is only available during the build is frightening; I even built my own tool to at least get some orientation using best-effort cross-referencing, see https://github.com/rochus-keller/GnTools.

BUSY has inherited a lot of ideas from GN, which itself has inherited ideas from Blaze (i.e. Bazel). GN improves over Blaze in different aspects, e.g. in that it has explicit conditionals and also configs (see e.g. https://gn.googlesource.com/gn/+/main/docs/language.md#Differences-and-similarities-to-Blaze). BUSY has both conditionals as well as configs, and it also has a few other concepts not present in GN or Bazel. The most obvious is static typing, which makes it possible to statically analyze and better understand build systems. I did quite some research in this respect and even implemented tools alone for this purpose (see e.g. https://github.com/rochus-keller/GnTools). Then it has an explicit path type with dedicated operators (instead of arbitrary strings), an explicit module concept with control of visibility, enumeration types with explicit member checks (instead of arbitrary string comparisons), mutable and immutable variables, and more flexible result handling over dependency chains, just to name a few. Well possible that Bazel has improved in these respects since I last looked at it.