CMake represents the peak build system. You're flogging a dead horse. The last thing we need is Yet Another Quirky Build System. On Thu, 4 Dec 2025 at 06:59, Hassan Sajjad via Boost <boost@lists.boost.org> 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...
_______________________________________________ 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/K2GPJBCG...