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.
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!
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.
The arrows don't go up...?
https://gittup.org/tup/
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.
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!
> 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.