Re: A proposal for a modern build-system

From: Hassan Sajjad (hassan.sajjad069_at_[hidden])
Date: 2025-04-19 17:19:30

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-papers/blob/main/generated/my-paper.html.
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_at_[hidden]>
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_at_[hidden]>
> 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-papers/blob/main/generated/my-paper.html
>> ,
>> 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
>>
>>
>>