Hi. I am seeking an endorsement of my software, HMake ( a library in a way (hconfigure) ), so that it can go through the review and possibly be included in Boost as a modern replacement for b2. Following is a comprehensive list of benefits that HMake provides compared to b2 or other build-systems. Some of this might not apply to one or the other. 1) Using C++ itself. You have to learn a library interface, but not a new programming language. 2) Single file for the whole build specification. 3) Needs very little maintenance or build-file modifications. You can use globbing patterns for specifying source and module files. Specifying tests can also be made simpler, e.g., with a convention to prepend a character in the file-name like (r, c), etc. (run, compile). And a JSON file if you expect any run to produce a particular output. So, you reconfigure when you add/delete a new test or modify the JSON file instead of first editing the build file. hmake.cpp file size is up to 10x smaller compared to CMakeLists due to C++ expressibility. 4) Very performant and efficient. On par with Ninja in both metrics, if not better. Some optimizations are still under development. 5) Multiconfig. You can build multiple configurations with one command. Has b2-inspired features/properties. 5) Fast configuration. Configuration will always be less than 5s ( even with up to 10 full Boost configurations on Windows ). 6) Very Extensible. Can be easily extended to support features like code generation, etc. The build algorithm allows for dynamic nodes and edges in the same process. No other does that. 7) Has header-units support, which, contrary to C++ modules, offers build-speed improvements without any source-code changes. The following are not yet implemented. But if you evaluate the above points, you can see that the following can be easily supported as well. 8) I wrote this paper https://htmlpreview.github.io/?https://github.com/HassanSajjad-302/iso-paper.... It is at most a 2-day work for a compile-dev to support this. This will allow 4x compilation speed improvement for Boost and even bigger gains for bigger projects. 9) HMake will support a feature called BigHu (described in previous email), which makes rebuilds incredibly fast as well. Also, I think header-units can be backported for older C++ versions as well, since they change semantics very little ( mostly around the preprocessor ). 10) HMake will also support https://lists.isocpp.org/sg15/2023/11/2146.php and https://lists.isocpp.org/sg15/2023/11/2106.php if these get implemented. 11) compile-commands.json support. HMake will generate these at configure time for the configurations being configured. 12) CMake integration support through CPS. Some features, like header-units might not work. 13) HMake will support multiple other programming languages, frameworks like iOS and Android app generation, different installers, etc. HMake is still a novel build-system that is under heavy development. A project of Boost size using this in production will provide highly valuable insights that will tremendously improve the HMake itself as well. HMake is written in C++20, follows best practices, is extensively tested, uses TDD, and the core library is around 15k C++ lines. I can also do a video call presentation of my software. This might be a quicker way to make yourself familiar with my software capabilities than reading documentation. Because I can do live examples and explain details accordingly. Best, Hassan Sajjad On Wed, Apr 16, 2025 at 5:21 PM Hassan Sajjad <hassan.sajjad069@gmail.com> wrote:
The interactions to reproduce the results. https://github.com/HassanSajjad-302/HMake/blob/main/Projects/Boost/hmake.cpp
On Wed, Apr 16, 2025, 16:34 Hassan Sajjad <hassan.sajjad069@gmail.com> wrote:
Hi.
I compiled 25 Boost libraries with C++20 header-units, including examples and Tests of a few. This resulted in a 1.44x speed-up if we exclude the scanning. Scanning was as slow as the header-unit build.
I have a solution for that. I am sending this paper (Making some final edits) https://htmlpreview.github.io/?https://github.com/HassanSajjad-302/iso-paper... , which allows for a build-system to use a scanning-less approach to build header-units.This method requires only minimal modifications to the compiler and enables memory-mapped file sharing, which significantly reduces filesystem overhead and further boosts speed.
My proposal for a scanning-less approach will allow HMake to have another amazing feature, monolithic Big header-units. BigHu will allow you to map all the headers from a directory to a single header-unit. This header-unit includes all these header-files and consumes them as header-files. Now, whenever the compiler requests a header-unit from this directory, the build-system instead sends this consolidated BigHu. This will not only improve the clean build speed, because of fewer process launches. But also massively boosts the rebuild speed as few header-units need to be read instead of lots of files. No source-code editing will be needed to use this feature. And you will have the option to either build a library as BigHu (if you don't mean to edit it) or as small header-units (if you are working on it).
HMake will soon support compile_commands.json, which I guess can work fine with header-units. Thus you can benefit from both, faster compilation and working intelliscence.
The API shown in hmake.cpp is a work in progress. HMake build-system benefits are numerous, even if we leave out the header-units support. This makes it a perfect replacement for B2. I believe we can complete the switch in the next 2 months. And if some compiler supports my paper, we get >3x faster compilation as well.
Best, Hassan Sajjad