On Thu, Feb 27, 2025 at 21:39 vspefs via Gcc <gcc@gcc.gnu.org> wrote:
> Current `-Mmodules` output is based on [P1602R0](wg21.link/p1602r0), which > speaks about a set of Makefile rules that can handle modules, with the > help of > module mappers and a modified GNU Make. > > The proposal came out in 2019, and the output of those rules was > implemented > at GCC in 2020. However, so far we still don't have a new release of GNU > Make > which implements P1602R0. > > What's more, the rules described in P1602R0 are not ideal. It sets up phony > prerequisites for real-file targets, causing guaranteed rebuilds. It is > also > unable to handle dependencies among module interfaces - that is to say, if > module A imports and exports B, then the interface of module A depends on > that > of module B, so its CMI should be rebuilt if the interface of B changes. > > I tried a few approaches to fix the current implementation, but in vain. > > It is possible, however, to have another set of Makefile rules generated, > which > solves all the problems, and doesn't need a new GNU Make. I've posted it in > reddit. > > See [here]( > https://www.reddit.com/r/cpp/comments/1izg2cc/make_me_a_module_now/). > > To briefly summarize the idea: > > > If an object target is built from a module interface unit, the rules > generated > > are: > > > > ```Makefile > > target.o: source.cc regular_prereqs header_unit_prereqs| > header_unit_prereqs \ > > module_prereqs > > source_cmi.gcm: source.cc regular_prereqs header_unit_prereqs \ > > module_prereqs| target.o > > ``` > > If an object target is not, the rule generated is: > > > > ```Makefile > > target.o: source_files regular_prereqs \ > > header_unit_prereqs| header_unit_prereqs module_prereqs > > ``` > > > > The `header_unit_prereqs` and `module_prereqs` are paths to the > corresponding > > CMI files. > > The patched GCC can be found [here]( > https://github.com/vspefs/gcc/tree/module-makefile-gen-fix). > > An example project can be found [here]( > https://github.com/vspefs/makefile-cxx-module). > > Best regards, > vspefs Could your approach simultaneously be used to have better dependency information for Fortran modules? I feel like there’s at least some overlap there. Regarding Fortran modules, it is possible to create both the .o and any needed .mod files from one compiler execution. You can tell GNU Make that a particular rule creates multiple files using a grouped target ( https://www.gnu.org/software/make/manual/make.html#Multiple-Targets), and older make has a work around using pattern rules. With a grouped target and knowledge of the modules that a translation unit will create, the make rules are straightforward. There’s not a whole lot of conceptual difference between that and these gcm files, right? If gcc could output a rule that a .o creates one or more .mod files for Fortran, or a whole lot of .gcm files for c++, then the same machinery could be used for both. >
