Support for Beast - The Build System

Hi! I am the creator of a new build system: Beast.
Beast is a build system focused on ease of use and speed. It works at the very base level and helps you build your projects easily. Compared to Make and Ninja, it is much easier to use syntactically and technically.

GitHub: https://github.com/GauravDawra/Beast/
Website: https://gauravdawra.github.io/Beast-docs/
It also has a lot of optimizations over Make. Overall, I believe it can be a tool be used by both: CMake and the end user directly.

I would thus like to know how I can contribute to CMake in order to introduce support for Beast. I want to build a generator inside CMake that generates Beast build files. I would like to discuss this further and how to go about it.

Thank you

Thanks for your interest. If you want to add Beast support to CMake, I’d suggest looking at the Make and Ninja generators for guidance. The code can be found in Source/cmGlobalNinjaGenerator.cxx, Source/cmGlobalUnixMakefileGenerator3.cxx, and the other files that they reference.

I do wonder, what exactly does Beast have that Make and Ninja do not? Ninja is very fast, and is specifically meant to be auto-generated by tools like CMake, and not hand-written.

Hi! Thanks for your reply @kyle.edwards !
I will surely take look at both Make and Ninja.
While researching for Beast, I found that Make has some inefficiencies when it comes to time stamps and managing files/targets. There are several other inefficiencies, and I believe this reply is not the right place to discuss those.
As far as Ninja is concerned, I believe that a build system, even if it works as a base, should be accessible and readable by a user. But then again this is just my ideology. I have created this tool so that it will be both user-readable/understandable and efficient.
Make has been used directly by users for a long time. Looking at the syntax and code for Beast you will find that it overtakes Make in both ease of use (in writing beast build files by hand) and efficiency!
I soon wish to add other features. But before that, via this post, I just wanted to make sure that indeed CMake admins will be interested in including Beast generator as a part of their amazing project!
Thanks once again Kyle!!

I don’t know yet if we’d be interested in adding this. At the very least, I’d want to see Beast mature more and have more widespread use. Feel free to patch CMake for your own use though, and maybe some day if Beast gains more traction we’ll consider upstreaming it.

I would start by copying the NinjaGenerator files and changing them to write out equivalent Beast files.

Some notes:

  • ninja supports pools, so that would probably need to be ripped out
  • ninja supports dyndep rules (in order to support Fortran and C++20 modules) and I see no equivalent support in Beast (from a cursory glance)

Other than that, I think the test suite should be able to validate just about everything else that might be of interest to CMake for a new generator.

Hi @ben.boeckel ! Thanks for the reply!
Yes, I will definitely check out the NinjaGenerator files in the repository.
About your notes, the reason why Beast doesn’t have all this is that it is very new. Right now it has all the basic features that allow it to be called a build system, but surely new features will be added in the future.
Also, could you please elaborate more as to what you mean by the “test suite”? I would definitely like for Beast to be integrated with CMake and am open to all suggestions for the same.
Thank you once again! Looking forward to your help

CMake has a set of unit tests and integration tests in the Tests directory that get run for each generator. Any new generator has to pass all these tests (or make a strong case for carving out an exception to the ones it fails) before it can be upstreamed.

Ok
I will definitely take a look. If Beast manages to pass these tests, does it mean that CMake will be interested in integrating it?

Again, I’d be wary of upstreaming support for such a new buildsystem with such little adoption. If it matures more, has more widespread usage, and can pass the entire CMake test suite, then maybe we’d consider it.

CMake support would certainly help. This MR adds an experimental mechanism by which we can add it without committing to it (the mechanism is that to use an experiemental bit, the user must set a variable to a specific UUID that we change every release or incompatible change to acknowledge the experimental-ness of the feature).

Thanks for your reply @ben.boeckel @kyle.edwards ,
thanks for the reply!
I will take a look and get back!