I just wanted to check, if support for c++20 modules for the ‘make’ generator will ever arrive. In another thread in 2023 it was mentioned, I would be nice, wanted, but it is not on the planning.
Now that, we nearly got also import std; in cmake (hopefully in the the next version of cmake, since 4.3.0 just didn’t cut it) there is another incentive for teams and project to start using modules.
But in many cases, the ‘make’ generator is in use, which means those teams and projects should first start planning a migration to Ninja (which will be problematic in some cases, I feel custom_targets might be problematic in some cases), or would the make support arrive in a planned future, because this might give the option to wait a little bit longer.
Personally I would say this would be nice, that support arrives, it is good to know the current, future options to help/coach teams on their transition path towards modules.
slow or not slow, that is not the point. See fmt library, it also tries to provide modules by means of a makefile, for the sheer same fact, not trying to push this dependency and build system switch on users.
Personally I am also in favor or Ninja, but that is one again not the point. There will be several teams, projects, who will try to avoid the cost to first switch to Ninja, and as such the adaptation of modules keeps being postponed and delayed in several areas.
I have tried on a codebase already ninja (did not further inspect, since there was no time), the build broke in many places due to the switch to ninja, while with make all was fine and running stable for a decade or more. As said, maybe the solution was simple, but there was no time to inspect.
First looking what the options are, or is there indeed no other choice, and it is a plain enforcement.
Than the next step is teaching those people how to switch to Ninja and record and document encountered problems so the entire community can learn from that.
The issues encountered when transitioning to parallel builds are well understood. Many legacy projects still rely on outdated CMake versions and deprecated practices. They often lack a clearly defined dependency graph, and in some cases even contain circular dependencies. These are not problems caused by Ninja or CMake itself.
Addressing this can be challenging, but it is necessary.
The first step is to modernize the CMake configuration. Once project files are updated to current standards, builds become significantly more reliable across all generators.