While you can read the documentation to see how HMake does header-units, you can instead run the boost example by following the following steps. Step - By - Step 1 You need Windows 2 You need the latest version of VS2022. 3 You need to compile my patch https://github.com/llvm/llvm-project/pull/147682 or you can instead use the pre-compiled binary https://drive.google.com/file/d/1agPjaVW65Ae10yUeuuqEGlh7WiigEiqg/view 4 Edit the last line of CppCompilerFeatures::initialize() to point to this fork 5 After downloading my software, you need to build it with CMake in Release mode with the latest visual-studio 2022. 6 Add the directory of the produced hhelper hbuild and htools in the path variable. I use clion and add the cmake-build-release. 7 Run htools with admin permissions. It create C:\Program Files (x86)\HMake\toolsCache.json file. 8 Download and un-zip from https://www.boost.org/releases/1.88.0/ 9 cd to the boost-1.88.0 10 copy the contents of HMake/Projects/Boost/* to here ( ArrayDeclarations.hpp and hmake.cpp) 11 mkdir Build 12 cd Build 13 hhelper 14 hhelper 15 cd huBig-d 16 ptime hbuild 17 cd ../conventional-d 18 ptime hbuild On my system conventional-d time was 2.3x higher than huBig-d time. Ultra-Fast Build is an experience of a kind. I have attached a sample output and screen-shots depicting colored output and a 10x speed-up in rebuild speed as well. To test rebuild, a random file Boost/libs/hash2/Tests/ripemd.cpp was edited. If endorsed and accepted, the whole boost can be compiled 7x faster in 1 month with all its configurations, docs and tests. On Thu, Dec 4, 2025 at 8:54 AM 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. I recently released 0.3 of my software. I have posted an exhaustive list of benefits of my software earlier in this thread.
I have added detailed documentation for the important API. And have completed implementation of non-scanning support of modules and header-unit in my HMake and in Clang https://github.com/llvm/llvm-project/pull/147682. Compiling this https://github.com/HassanSajjad-302/HMake?tab=readme-ov-file#boost-example results in 2.3x speed-up on my system. Instead of compiling my fork, you can use this https://drive.google.com/file/d/1agPjaVW65Ae10yUeuuqEGlh7WiigEiqg/view instead. Earlier I estimated the speedup to be >5x. My new estimate is >7x. Only 5 were successfully compiled as big-hu. And currently, shared memory BMI support is yet to be added in Clang.
hmake.cpp of the Boost can be simplified a lot with a better front-end API. HMake has a great backend (BTarget, Builder, Node, TargetCache) and middle-end (CppTarget, CppSrc, CppMod, LOAT) API. However, its frontend API to create and feed the middle-end data structures can be further improved. Also, an invariant I followed while writing the hmake.cpp was to not modify the boost source-code at all. If there is some liberty to do that, the hmake.cpp could be so much simpler. In non-scanning build, the build-system needs a little more info like the list of header-files and header-units as not every header-file can be a header-unit. This could instead be supplied in a module-map file in a directory. In boost in Tests/ and Examples/ jam files every test has to be declared as run, compile, link, link-fail etc. Instead this info could be encoded in test name instead like r_test-name, c_test-name, cf_test-name. A file test-info could be further supplied which has the info about the output of the running tests. So, for now please review just the back-end and middle-end and be assured that completed hmake.cpp will be less than 1000 lines of easy to read and understand C++ code. With concerted, unanimous effort, it would take less than month to complete this.
Best, Hassan Sajjad
On Mon, Jul 7, 2025 at 8:59 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 7 Jul 2025 15:45, Artyom Beilis via Boost wrote:
Removing C++03 compatability from many libraries and breaking Boost.ASIO in 1.87 seriously damaged the Boost reputation.
Boost breaking compatibility is the Achilles heel of Boost since I remember it (around 1.33) and it had never changed. It makes Boost highly problematic - almost irrelevant for any long term C++ project that needs to run over a large range of platforms that provide its own Boost. More than that, Boost is almost impossible to use in libraries or other interfaces because of breaking API/ABI virtually in any situation.
FWIW, I've been actively using Boost in the projects I worked on for around 25 years now. Those were long-term projects, some lasted for a decade or more (while I worked on them) and some gradually transitioned from C++03 to C++17 in their lifetime. And yes, the Boost version that was used was being regularly upgraded while the projects were maintained and developed. And yes, we were building Boost ourselves. Granted, in those projects, we didn't care about ABI stability, but as for API stability, it's been surprisingly smooth considering the age and amount of changes that go into Boost. My experience may be subjective and not very representative, given that I'm also a Boost maintainer, but I really can't say that using Boost was "impossible" or "highly problematic".
I admit there are use cases where ABI is much more important, but I also do not think stable ABI is a mandatory requirement in every use case. Stable ABI also has a cost; maintaining it just for the sake of it is a waste of effort and an obstacle to library evolution.
_______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/ZU5UNK5U...
