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@gmail.com> 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-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

Generally speaking your "benefits list" has quite bold statements

Are you proposing replacement of b2 for Boost or just yet another build system to the club?

These statements are based on concrete evidence. I am proposing to replace b2. And why is it good? I mean you need to have a really good point to make

build system that uses C++ files to define a build...

3x faster compilation in Release and >5x faster in Debug mode for Boost and better for bigger projects. No other build-system can do that. HMake will have a few other game-changing features in the future as well. It is not possible to evolve a DSL based build-system like that.

I mean today CMake is the most common industry standard build system

that works really well. Why would you want to use it over something like this?

CMake can not support C++20 header-units. One benefit that I forgot is that once you have compiled your project with header-units in HMake and you want to move to C++20 modules, you do not need to make a single edit in your configuration file (Not true for projects like Boost which want to support both header-files and modules. In this case some macro definitions will be needed). With this, #10 and #8, C++20 modules and header-units become an absolute bliss to use with HMake. See build systems run multiple tests (cmake, autotools and others) to make

sure that everything is as expected. How exactly do you think you'll be able to speed it up? Because most of the configuration time is actually performing checks like potential dependencies, test builds, etc.

By caching the results and not running tests every time. Also, configure.exe uses the same code that is used by build.exe. It is fully parallel as well. Now I don't want to discourage you but it is a really non-standard

approach to build.

Isn't it superior, though? And on more technical details: while it is more than ok to share ideas,

generally speaking seeking of an endorsement is something done to get ready for a review... Not sure it is even close to it.

How so? Best, Hassan Sajjad On Mon, May 5, 2025 at 5:49 PM Artyom Beilis via Boost < boost@lists.boost.org> wrote:

Hi,

...

Following is a comprehensive list of benefits that HMake provides

compared

...

to b2 or other build-systems.

Generally speaking your "benefits list" has quite bold statements

Are you proposing replacement of b2 for Boost or just yet another build system to the club?

...

1) Using C++ itself. You have to learn a library interface, but not a new programming language.

And why is it good? I mean you need to have a really good point to make build system that uses C++ files to define a build...

...

4) Very performant and efficient. On par with Ninja in both metrics, if not better. Some optimizations are still under development.

So how would it be better than just old good cmake + ninja?

I mean today CMake is the most common industry standard build system that works really well. Why would you want to use it over something like this?

Serious question that needs a deep answer.

...

5) Fast configuration. Configuration will always be less than 5s ( even with up to 10 full Boost configurations on Windows ).

See build systems run multiple tests (cmake, autotools and others) to make sure that everything is as expected. How exactly do you think you'll be able to speed it up? Because most of the configuration time is actually performing checks like potential dependencies, test builds, etc.

Now I don't want to discourage you but it is a really non-standard approach to build.

And on more technical details: while it is more than ok to share ideas, generally speaking seeking of an endorsement is something done to get ready for a review... Not sure it is even close to it.

Regards, Artyom

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

I have reservations about this. I am not in favor of rewriting the configuration selection for the various combinations of architecture, binary format, address model, and ABI. This would require significant effort and could introduce unnecessary complexity, given the work already invested in the current implementation.

HMake API has features / properties inspired by / mapped on b2 features. On Tue, May 6, 2025 at 12:18 PM oliver.kowalke--- via Boost < boost@lists.boost.org> wrote:

06.05.2025 00:59:04 Hassan Sajjad via Boost <boost@lists.boost.org>:

...

I am proposing to replace b2.

I have reservations about this. I am not in favor of rewriting the configuration selection for the various combinations of architecture, binary format, address model, and ABI. This would require significant effort and could introduce unnecessary complexity, given the work already invested in the current implementation.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

. I am proposing to replace b2.

While I can agree that b2 isn't particularly good build system by any stretch of imagination There was a long and yet incomplete effort of moving to CMake that most around there are familiar with. CMake works very well and is very well supported all around. Replacing one not-so-good homebrew system that was at least polished with yet another homebrew system is a horrible idea. Boost needs _less_ of "non-invented-here-syndrome": not _more_ of it Refrasing Stroustrup there are two types of build systems - everybody complains about and nobody uses, and cmake is one everybody is complaining about ;-)

I mean today CMake is the most common industry standard build system

...

that works really well. Why would you want to use it over something like this?

CMake can not support C++20 header-units. One benefit that I forgot is that once you have compiled your project with header-units in HMake and you want to move to C++20 modules,

It seems like a feature gap that can be fixed at CMake level - either by cmake developers or by external patch. Have you considered talking with CMake developers about it and/or submitting a patch? What do they think about this? I'm sure they are aware of the problem :-)

By caching the results and not running tests every time. Also, configure.exe uses the same code that is used by build.exe. It is fully parallel as well.

You don't reconfigure each and every build... cmake caches _a lot_ sorry but it seems to be a false statement. Best Artyom

On Tue, May 6, 2025 at 5:05 PM René Ferdinand Rivera Morell <grafikrobot@gmail.com> wrote:

On Tue, May 6, 2025 at 2:52 AM Artyom Beilis via Boost <boost@lists.boost.org> wrote:

...

...

. I am proposing to replace b2.

While I can agree that b2 isn't particularly good build system by any stretch of imagination

Specific build systems, and all software, has advantages and disadvantages. We would benefit from feedback as to improvements we can make to our tools.

See, I discussed it a lot back in 2011 on this list. As bottom line when I worked on Boost.Locale having large experience with both, autotools cmake and even basic makefiles I totally failed to perform all tasks I needed I don't recall exactly but basic stuff like finding 3rd party libraries or conditional builds was total nightmare and very hard to maintain. Compare for example cmake: https://github.com/boostorg/locale/blob/develop/CMakeLists.txt and jamfile https://github.com/boostorg/locale/blob/develop/build/Jamfile.v2 that is twice as large and some tests that are built in in cmake (like test header/library) are generated in separate build The concept of "conditional flags" per build makes anything beyond simple tasks very challenging I couldn't complete the build system on my own and Vladimir Prus had come to my rescue... Even after that I failed to create conditional tests (so I just put ifdef to make them do nothing) but I think Alexander Grund that took the maintenance from me and does absolutely amazing job had fixed it, Bottom line, in my opinion bjam is a very limited build system. Maybe it servers Boost ok, but I would never choose one outside the scope mostly due its design of doing everything in the same flow under all conditions rather than the much simpler and easy to use CMake approach. I don't tell cmake is perfect - ohhh boy it isn't but I find it much more manageable, easy to use and well documented. Maybe stuff had changed since 2011 but for me it was very unpleasant experience, and I worked with autotools that were surprisingly simpler to use (at least for me) So take my words with a grain of salt :-) Artyom

On Tue, May 6, 2025 at 10:39 PM Дмитрий Архипов via Boost <boost@lists.boost.org> wrote:

вт, 6 мая 2025 г. в 17:55, Artyom Beilis via Boost <boost@lists.boost.org>:

...

See, I discussed it a lot back in 2011 on this list.

As bottom line when I worked on Boost.Locale having large experience with both, autotools cmake and even basic makefiles I totally failed to perform all tasks I needed I don't recall exactly but basic stuff like finding 3rd party libraries or conditional builds was total nightmare and very hard to maintain.

Compare for example cmake: https://github.com/boostorg/locale/blob/develop/CMakeLists.txt and jamfile https://github.com/boostorg/locale/blob/develop/build/Jamfile.v2 that is twice as large and some tests that are built in in cmake (like test header/library) are generated in separate build

I looked at those two files. As far as I can see, the vast majority of that jamfile is configuring dependencies, particularly Iconv and ICU. The only reason there's nothing similar in the CMakeLists.txt is because there are Find modules for those libraries provided with CMake. Ironically enough, they were not provided with CMake in 2011 (FindICU is provided since version 3.7 which was released in 2016, FindIconv since version 3.11 released in 2018). Moreover, things like private/public properties were only added to CMake in 2013. Again, ironically as an effort to copy b2 usage requirements.

Actually in cppcms/booster.locale original cmake (where boost.locale came from) I used one liners to find headers and libraries only difference was for debug build to find iculibrary with "d" suffix, I didn't use predefined FindICU Now finding 3rd part library is the central part of the configuration/build system for real world projects. Looking as an example at my big FOSS C++ project dependencies CppCMS: icu, zlib, openssl/gnu-tls, iconv, pcre, python CppDB: mysql, odbc, postgresql, sqlite Dlprimitives: python, sqlite, OpenCL, protobuf, openblas/cblas, hdf5, boost-python, boost-numpy OpenLiveStacker: libtiff, cppcms, libcurl, indilib, indigo, libraw, libgphoto, opencv, cfitsio, libusb, asisdk, touptek sdk, zlib, android camera2 And finding each of them in CMake is virtually two lines (header, library) and I rarely use FindXXX with exception of some complex stuff (ironically boost python) So Boost is quite a unicorn when the vast majority of the libraries are header only or come with 0 dependencies and using icu in Regex in Locale was a major event. So from the point of view of somebody who comes from outside it is bare practicality and simplicity of using/configuring the dependencies.

...

Bottom line, in my opinion bjam is a very limited build system. Maybe it servers Boost ok, but I would never choose one outside the scope mostly due its design of doing everything in the same flow under all conditions rather than the much simpler and easy to use CMake approach.

I can agree that it could be more easy to think in exactly one configuration. Which makes writing b2 build scripts properly more challenging than CMake build scripts. But ironically again, this part of b2 complexity also gradually enters CMake due to multiconfig generators (just look at generator expressions). Nevertheless, I find it strange that you call b2 very limited compared to CMake, when it's actually more powerful, and it's exactly that power that incurs complexity.

I understand what you are talking about because for windows build there is a huge matrix of Under Windows {Release,Debug}x{DynamicLink,StaticLink}x{DynamicRuntime,StaticRuntime} And under Linux it is typically shared object and static object - BTW something that autotools did very well and drive me crazy at the beginning with CMake - autotools buid automatically shared object and static while in cmake it is more verbose Now typically under windows you have two Debug and Release runtimes because they are ABI incompatible (not going to why they did such a dreadful decision - but it is another topic) So there is a mode in cmake that tries to build them both - and it does not work well that is why I never support VS projects with dual builds in my cmakes and tell windows users grab ninja and do a separate build for each of the debub or release configurations. So yes for building crazy matrices bjam helps a lot I totally agree - but all this till you need to find appropriate dependency for each and every case and turn on/off a feature if you found it or not - and not it becomes a nightmare since you may found ICU for dynamic linking in release but not for static linking or not for debug. So I do understand practicality of Boost Build bjam for Boost itself (as long as you don't need any 3rd party) but I find it rather unpractical for outside of the Boost crib Artyom

On Tue, May 6, 2025 at 12:52 AM Artyom Beilis via Boost < boost@lists.boost.org> wrote:

...

. I am proposing to replace b2.

While I can agree that b2 isn't particularly good build system by any stretch of imagination

There was a long and yet incomplete effort of moving to CMake that most around there are familiar with. CMake works very well and is very well supported all around.

Replacing one not-so-good homebrew system that was at least polished with yet another homebrew system is a horrible idea.

Boost needs _less_ of "non-invented-here-syndrome": not _more_ of it

This actually seems like a fantastic time to shill this Python script I've been working on. It lives here: https://github.com/cmazakas/boost/blob/c2py/c2.py This is intended to be a full drop-in replacement for b2. Right now, it only works on Linux but that's because I want a quality implementation before I work on a cross-platform solution. I'm actually chatting with one of the CMake devs on slack about how to alter the generation of the Ninja files. I might just manually patch them myself in the interim though. You can invoke it similarly to b2 today: ./c2.py \ hash2 test \ --cxxstd 11,20 \ --variant debug,release \ --address-model 64 \ --toolset clang-19,gcc-14 \ --asan --ubsan \ --ctestflags="--output-on-failure -R 'xxh3'" \ --no-cmake \ -j20 What this tool does is, it generates a series of CMake build directories under `build_c2py`, configuring each project in parallel and then builds the tests in parallel using recursive Make invocations. It's not as fast as b2 is but because it uses CMake, it really, really opens up the door for us. I've been thinking about looking for beta testers. I use this script daily to drive my work with the Alliance. The script is woefully incomplete but I think it's a good first step. - Christian

On Tue, May 6, 2025 at 7:46 AM Peter Dimov via Boost <boost@lists.boost.org> wrote:

Christian Mazakas wrote:

...

You can invoke it similarly to b2 today:

./c2.py \ hash2 test \ --cxxstd 11,20 \ --variant debug,release \ --address-model 64 \ --toolset clang-19,gcc-14 \ --asan --ubsan \ --ctestflags="--output-on-failure -R 'xxh3'" \

--output-on-failure (and --no_tests=error) should be the default, really.

Great call! I can update the script to do that trivially.

...

--no-cmake \

What does --no-cmake do?

I should update the name but it makes the script skip the CMake configuration phase. Right now, the script uses a very simple and naive mangling scheme for creating the names of build directories. A goal of mine was to have them be quasi-human readable so that way a frustrated user could intuitively inspect a specific build configuration so like b2, I don't include any passed cxxflags in the mangled name. To make sure that an accurate configuration is always used, I delete the existing CMakeCache.txt if it was there, which means a full re-configuration by CMake. `--no-cmake` is a flag used to skip this part and instead `make -C build_c2py` is invoked directly.

...

-j20

Ha, in the ideal world I suppose we'd check for the available number of CPUs and default to the max available. This is the value passed down to the Make invocation. - Christian

It seems like a feature gap that can be fixed at CMake level - either by cmake developers or by external patch.

Have you considered talking with CMake developers about it and/or submitting a patch? What do they think about this?

This is a little funny. If CMake developers can not, how can I? I can only talk about how my build-system supports header-units. Also, I should not have said, "CMake can not support C++20 header-units". Anything is possible. Header-Units support is built on the following four features in HMake. 1) Next-Gen build-algorithm HMake build-algorithm support both dynamic nodes and dynamic edges. CMake supports modules through Ninja, which only supports dynamic edges. Example6 and Example7 in HMake Architecture section demonstrate this capability. 2) Vertical Integration HMake is both a build-system generator and a build-system itself. Ninja supports dynamic edges through a separate process. While building modules, it launches a new process that consumes all of the scanning output and outputs a file in Ninja consumable format. Ninja then consumes this file to learn about the dynamic edges. While HMake does all of this itself. Suppose Ninja supports dynamic nodes, and even then, to ensure a header unit is built before the consumer, it will need to launch a new process to establish the dependency. It will have to do this every time it discovers a new header-unit. And even then, it will have to determine what compile-command to use with that header-unit. Suppose the user wants to build ASIO with ASIO_STANDALONE. Only the ASIO header-units should be built with this macro. ASIO header-units can potentially be discovered in any of its dependent targets. HMake goes over the list of header-unit-includes to determine the directory from which this header-unit is coming. And then the mapping of the directory to target to determine the cpptarget to attach this header-unit to. i.e the target whose compile-command will be used to compile this header-unit. Ninja lacks the context to do all this. CMake will have to turn to a build-system itself to support header-units. 3) Game-Changing Feature, Node HMake has another feature called Node (explained in documentation). For a module file, to support incremental build, HMake caches its header-includes, module-deps, header-unit-deps, compile-command, scanning-command. Without the Node feature, this cache will explode. Node feature results in little build residue. I estimate that for full Boost, for full Configuration, it will be 1MB. This ensures ultra-fast loading, ultra-fast performance. 4) C++ While this is often contended, I think this is extremely important. E.g., now I plan to remove the scanning support and add scanning-less support. C++ allows for quick iteration. It allows one to focus on the problem instead of the DSL. All in all, as it stands, this is a fundamental change. Best, Hassan Sajjad On Tue, May 6, 2025 at 12:52 PM Artyom Beilis via Boost < boost@lists.boost.org> wrote:

...

. I am proposing to replace b2.

While I can agree that b2 isn't particularly good build system by any stretch of imagination

There was a long and yet incomplete effort of moving to CMake that most around there are familiar with. CMake works very well and is very well supported all around.

Replacing one not-so-good homebrew system that was at least polished with yet another homebrew system is a horrible idea.

Boost needs _less_ of "non-invented-here-syndrome": not _more_ of it

Refrasing Stroustrup there are two types of build systems - everybody complains about and nobody uses, and cmake is one everybody is complaining about ;-)

...

I mean today CMake is the most common industry standard build system

...

that works really well. Why would you want to use it over something like this?

CMake can not support C++20 header-units. One benefit that I forgot is that once you have compiled your project with header-units in HMake and you want to move to C++20 modules,

It seems like a feature gap that can be fixed at CMake level - either by cmake developers or by external patch.

Have you considered talking with CMake developers about it and/or submitting a patch? What do they think about this?

I'm sure they are aware of the problem :-)

...

By caching the results and not running tests every time. Also, configure.exe uses the same code that is used by build.exe. It is fully parallel as well.

You don't reconfigure each and every build... cmake caches _a lot_ sorry but it seems to be a false statement.

Best Artyom

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hi Marcin,

Has this feature been implemented in any compiler? Upstreaming such a change to LLVM would demonstrate that it is mature enough to be used in production software and also provide a stamp of approval.

Not yet. This is the next step. I can not add no-scanning build support without this, without which there can not be a useful drop-in header-units replacement. It won't be easy to convince the community to switch to a new build system

that requires modification to the C/C++ compiler. These are often unlikely to be adopted unless there is a significant demand for that feature in the community.

The changes required are minimal. Check the README in this repo https://github.com/HassanSajjad-302/ipc2978api. I also added small modifications to the paper. I am confident that Clang will accept the changes. Here is a comment from Clang dev and Tooling Study Group chair https://www.reddit.com/r/cpp/comments/1jb8acg/comment/mhvvfva/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button I would also like to add that this isn't related to the design of modules.

Despite lots of claims, I have never seen a proposed design that would actually be any easier to implement in reality. You can make things easier by not supporting headers, but then no existing code can use it. You can also do a lot of things by restricting how they can be used, but then most projects would have to change (often in major ways) to use them. The fundamental problem is that C++ sits on 50+ years of textual inclusion and build system legacy, and modules requires changing that. There's no easy fix that's going to have high perf with a build system designed almost 50 years ago. Things like a module build server are the closest, but nobody is actually working on that from what I can tell.

Best, Hassan Sajjad On Tue, May 6, 2025 at 7:07 PM Marcin Copik <mcopik@gmail.com> wrote:

Hi Hassan,

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.

Has this feature been implemented in any compiler? Upstreaming such a change to LLVM would demonstrate that it is mature enough to be used in production software and also provide a stamp of approval.

It won't be easy to convince the community to switch to a new build system that requires modification to the C/C++ compiler. These are often unlikely to be adopted unless there is a significant demand for that feature in the community.

Best, Marcin

...

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

...

...

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

...

...

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

examples header-unit 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

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

I’m happy to be wrong but don’t suspect that creating a new build system from scratch (without massive commercial backing) is likely to be a path of minimal resistance.

I stay motivated because HMake has a lot of benefits compared to the competitors. Commercial backing will indeed be seriously helpful. On Tue, May 6, 2025 at 6:43 PM Jonathan Coe via Boost <boost@lists.boost.org> wrote:

Hi,

Sharing my thoughts so that the HMake author does not invest time unduly.

Even with exceptional and detailed documentation, this feels like a high-risk change that’s very unlikely to take place without evidence of significant adoption elsewhere. Build systems are hard and most folk seem to prefer familiar foibles over innovation.

If the build system space is interesting, it might be worth spending time improving existing tools (tooling around CMake is challenging) rather than starting from scratch.

I’m happy to be wrong but don’t suspect that creating a new build system from scratch (without massive commercial backing) is likely to be a path of minimal resistance.

J

...

On 6 May 2025, at 13:26, Дмитрий Архипов via Boost < boost@lists.boost.org> wrote:

ср, 16 апр. 2025 г. в 15:22, Hassan Sajjad via Boost < boost@lists.boost.org>:

...

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.

If this is a request for endorsement, then the problem is that the tool/library in question is not really documented. First, compare your README with CMake's tutorial

https://cmake.org/cmake/help/latest/guide/tutorial/A%20Basic%20Starting%20Po...

...

or B2's tutorial https://www.bfgroup.xyz/b2/manual/main/index.html#b2.tutorial. Both explain what file to create, what to put in there, what command to invoke from the shell. Your simple C++ example (https://github.com/HassanSajjad-302/HMake?tab=readme-ov-file#c-examples ) starts in the middle of the file, and is definitely more hand-wavy. After reading the paragraphs following the code snippet I am not sure what commands I need to invoke.

So, a supposed benefit of HMake is that you don't need to learn a new syntax. But learning a new library's API can be a significant task on its own.

void updateBTarget(class Builder &builder, unsigned short round) override

What is a "round" here? I am pretty well-versed in build system lingo, and I have no idea. In the following paragraph you explain that it is related to how C++ modules are built (in HMake and in CMake). There are no "rounds" in C++ modules spec or in CMake's document on how to use it with modules. So, this concept is particular to HMake. This highlights the fact that you need a thorough documentation of the API. WIthout it your tool/library is unusable in a serious scenario.

Let's now compare a minimal C++ project in CMake, B2 and HMake.

// HMake #include "Configure.hpp" void configurationSpecification(Configuration &config) { config.getCppExeDSC("app").getSourceTarget().sourceFiles("main.cpp"); } void buildSpecification() { getConfiguration(); CALL_CONFIGURATION_SPECIFICATION } MAIN_FUNCTION

# CMake cmake_minimum_required(VERSION 3.12) project(Tutorial) add_executable(app main.cpp)

#B2 exe app : main.cpp ;

I don't see how HMake is an improvement. It's neither shorter nor more readable. For example, waht is "DSC"? This also highlights a common annoyance with using a regular programming language for build scripts: build scripts connect sources with targets, their names are strings, so you have to use a lot of quoting.

Finally, let's consider getConfiguration. From the README I gather that the build script has to contain a description of every configuration that the project supports. That is, users can't experiment with a new configuration without modifying the build script. This is completely inadequate in my opinion. It is particularly inadequate for open source software projects. From the same description I gather that hmake also has to create a dedicated directory for each configuration. Note that the current main build system Boost uses (B2) does not work like that. It creates configurations on the fly from the user's build request and the targets' requirements. There's also no "active configuration" in B2, it can build multiple configurations simultaneously.

My main point is still the lack of documentation. Without documentation there could be no discussion of endorsement, as we simply cannot evaluate what to endorse.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

ср, 7 мая 2025 г. в 01:25, Hassan Sajjad <hassan.sajjad069@gmail.com>:

Specifying new Configurations is very easy. Like boost/hmake.cpp had the following two configurations defined to benchmark the debug build with header-units.

getConfiguration("conventional").assign(TreatModuleAsSource::YES, ConfigType::DEBUG); getConfiguration("hu").assign(TreatModuleAsSource::NO, TranslateInclude::YES, ConfigType::DEBUG);

Creating build-dirs at build-time will be very slow. HMake creates these in parallel at configure-time.

The issue here is not that it's hard to create new configurations. The issue is that the project's build scripts aren't an appropriate place for this. I shouldn't need to change files that are checked into version control system in order to just build the project for my system.

This is a recurrent complaint, so I concede. But I don't know where to start. I will be happy if you provide more ideas.

Meson (https://mesonbuild.com) is a relatively new build system. It has fairly well-organised and pretty documentation. You can start by copying its basic structure. You also definitely need a reference documentation for your library.