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 functionality.
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 dynamically typed (like most build systems) 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.
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!
I recently added a Ninja backend and a users guide and thought this might be helpful for a lot of people. It was pretty stable over the years. I have a few features on my todo list which I will implement as needed, and I recently completed my LeanDoc document language and migrated most of my specifications, which sparked further activities.
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.
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.
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 a good idea to possibly even integrate the build system directly.
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.
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 functionality.
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 dynamically typed (like most build systems) 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.
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!
I recently added a Ninja backend and a users guide and thought this might be helpful for a lot of people. It was pretty stable over the years. I have a few features on my todo list which I will implement as needed, and I recently completed my LeanDoc document language and migrated most of my specifications, which sparked further activities.
> 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 always wonder why use a DSL while you can just borrow some existing PL?
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.
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.
Same with build systems.
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 a good idea to possibly even integrate the build system directly.
Using Lua is a fatal flaw. As a C++ programmer I don't want to learn yet another language for a build system.
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...
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.
Looks like here lua vm is used as the basis for the project itself not as the language u write your builds with