BUSY

The build files aren’t written in Lua. It defines its own language. The user’s guide seems like the place to start: https://github.com/rochus-keller/BUSY/blob/main/docs/The_BUS...

> Why post it now? Apparently a explanatory document has been extended in a recent commit [1]. Maybe the project is waking up. [1]: https://github.com/rochus-keller/BUSY/commit/d92677084114619...

I don't want to burden you with work, so don't feel obliged in any way. This is simply my opinion (there are also good reasons for newer C versions). In all my personal projects, I don't have any newer versions than C99 or C++11 (most are even C++98/03). I recently even migrated a compiler backend framework from C++17 to C++11 to use it: https://github.com/rochus-keller/eigen/. I could do the same with your code if I would use it, but first I have to move forward in other projects. Concerning cmake: I only use it if unavoidable; instead I implemented my own build system (https://github.com/rochus-keller/busy/) some years ago which I now use for most of my personal projects.

> a large Starlark codebase is a large Python codebase, and large Python codebases are imperative, untyped, and can get messy even without all the things mentioned above. Even though your Starlark is pure and deterministic, it still easily ends up a rats nest of sphagetti This brings it to the point. I'm still wondering why the achievements of software engineering of the past fifty years, like modularization and static type checking had apparently so little influence on build systems. I implemented https://github.com/rochus-keller/BUSY for this reason, but it seems to require a greater cultural shift than most developers are already willing to make.

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

That's one part of the story; LeanCreator is rather "derived from" than "based on" QtCreator, because there was a lot of refactoring and redesign; it's also important to note that it uses the BUSY build system which is fully integrated with the IDE with semantic navigationt through the build specification files (instead of qmake, see https://github.com/rochus-keller/busy); and with "stripped-down" and "lean" I mean that I kicked out all stuff I never touched during the last twenty years.

> 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

My new BUSY build system specification language (https://github.com/rochus-keller/BUSY/blob/main/README.md) and of course Oberon+ (https://github.com/rochus-keller/Oberon/blob/master/README.m...).

We already have serious incompatibility problems with projects using autotools vs CMake vs Meson vs GYP vs Boost.Build vs SCons vs ... and now we throw BUSY (https://github.com/rochus-keller/BUSY/) onto the pile. Why do people continue to invent new build systems? Why should we care that BUSY is statically typed?