Re: A proposal for a modern build-system

From: Hassan Sajjad (hassan.sajjad069_at_[hidden])
Date: 2025-05-01 00:01:03

Hi.

I would like to share a little more info. The speedup mentioned (1.44x) was
achieved in Release config. I tested in Deubg config as well. Speed-up was
1.89x. So, the expected speed-up would be >3x in Release and >5x in Debug
for the full Boost.

Best,
Hassan Sajjad

On Sat, Apr 19, 2025, 22:19 Hassan Sajjad <hassan.sajjad069_at_[hidden]>
wrote:

> 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
>>>
>>>
>>>