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