https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467
--- Comment #8 from Ben Boeckel <bugzilla.gcc at me dot benboeckel.net> --- > Some people even claim that properly supporting Make to build C++ modules is > not possible if you want to make it actually production quality and reliable. It is possible, but, AFAIK, requires at least one level of recursive make (to deal with the dynamic files). Note that CMake also generates POSIX Make and only uses GNU-specific things to disable things like builtin rules. > GNU make still is the most common usage for build systems out there. Overall? Sure; I don't have data to say otherwise. For C++ modules? Highly unlikely unless autoconf/automake started relying on the non-GNU `fdep` [1] project. My concerns include: - tools have learned to read the *restricted* syntax historically used by `-MF` output and would need to grow new logic to deal with the `+=` usage - the variable name is hard-coded I think the following flags make sense to add: - `-Mmodules` to explicitly request this extra information - `-Mno-modules` to suppress it - `-MMV varname` to select the variable name used (though maybe `-Mc++module-variable=<varname>` is better) > Anyways gcc should work best with gnu software and cmake is not at all gnu > software and it competes with autoconf and automake which are gnu tools. I eagerly await C++ module support in autoconf and automake in that case. AFAIK, the support is in GNU make only and significant infrastructural support is missing from autoconf/autotools to reliably support them (namely things like installation assistance, enforcing visibility of modules between libraries, and not using stale module files). > Cmake is less portable than the autotools. There is a significant set of platforms that CMake supports that autotools does not, but yes…CMake certainly supports fewer total number platforms than autotools (though when weighted by relevance…). I'd say there's not a total ordering here. [1] https://gitlab.mpcdf.mpg.de/elpa/elpa/-/tree/master/fdep FD: CMake developer and primary implementer of C++ module support in it.
