A statically typed, cross-platform, easily bootstrappable build system

Join the discussion

• Hacker News
• Using Lua is a fatal flaw. As a C++ programmer I don't want to learn yet another language for a build system.
  by Panzerschrek
• 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...

  by skybrian
• 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!!
  by yr_animesh
• 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.
  by Rochus
• I always wonder why use a DSL while you can just borrow some existing PL?
  by xiaoyu2006
• 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.

  by nine_k
• 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.

  by socalgal2
• 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!
  by drunken_thor
• > 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...

  by nine_k
• 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.
  by Rochus
• 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.
  by lioeters
• 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.
  by Rochus