I like the focus on simplicity, staying with C and no other requirements, and the choice of Lua. I'm a casual user of CMake but not too enthused about it, so I'll give this a try. Honestly I don't know if static typing is that important for me in this particular use case. I may just rummage through the codebase to see if I can extract a few choice funcionality.
Static typing is important when you have a large project. I spent much time with the Chromium source tree and its GN build system which is statically typed and thus you have to actually run it (with every possible combination of parameters) to fully understand it and find bugs. I was looking for a build system for my LeanQt and LeanCreator projects (> 1 MSLOC) and eventually built my own, which was quite a natural thing given my experience with the implementation of statically typed languages.
That makes sense, how larger projects benefit from static typing not only for the project itself but the build process. And how it helps with reliability and predictability during the compilation step, instead of finding out during run time.
Your other projects look interesting too, they seem friendly for new learners to pick up. And the fact that you've been using your own build system, frameworks, etc., for some years already is a great signal that they're practical and useful. Thanks for sharing, I'm looking forward to exploring more.
Existing PLs are often excessively powerful and complex in some aspects, and not powerful or ergonomic enough in other aspects, pertaining to a particular subject area.
A good DSL makes certain things easy, and deliberately does not support some other things. Think about bash; imagine how bothersome it would be to use e.g. unchanged Python (one of the most readable languages) as a shell language.
My experience with Scons tells me you do not want a PL. The problem with a PL is every programmer that touches it implemenents a new way to do something and then trying to edit/change anything because like untangling noodles. That's not to say they can't do the same in a DSL but I'd argue the DSL fights against that trend.
There are also things like trying to find what needs to be built as fast as possible. This was also a problem with Scons as each person adds custom code that must be executed before being able to know what to build. Contrast that with gn and ninja which generate fast and build fast.
It seems like this was built years ago but only posted now. Why post it now? It doesn’t seem like it has changed much in 4 years so I can’t see that it matured or stabilized over that time. I am sorry for my ignorance of c build systems, this very well might be in high use already.
Either way, it looks useful and built by hand so good job! Looks great and I hope people find it useful!
It's even worse. Learning Lua may be at least a little bit useful for other tasks. Learning some language specific for this tool is just waste of time.
So it is an alternative for CMake build systems?? The idea is quite new to me, I have only used CMake to build my low latency systems project... Lets use this!!
I use it instead of qmake and cmake for all my projects since four years. It is most beneficial when used with large, standalone systems that must be built from the ground up for different platforms, and where it is best to integrate the build system directly.
16 comments
[ 183 ms ] story [ 734 ms ] threadYour other projects look interesting too, they seem friendly for new learners to pick up. And the fact that you've been using your own build system, frameworks, etc., for some years already is a great signal that they're practical and useful. Thanks for sharing, I'm looking forward to exploring more.
A good DSL makes certain things easy, and deliberately does not support some other things. Think about bash; imagine how bothersome it would be to use e.g. unchanged Python (one of the most readable languages) as a shell language.
Same with build systems.
There are also things like trying to find what needs to be built as fast as possible. This was also a problem with Scons as each person adds custom code that must be executed before being able to know what to build. Contrast that with gn and ninja which generate fast and build fast.
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...
https://gittup.org/tup/
The user’s guide seems like the place to start:
https://github.com/rochus-keller/BUSY/blob/main/docs/The_BUS...