GCC conjures up both .o file and .gcm file in one invocation when possible, too. And yes, that can be managed well with grouped target - but a rule with grouped target must have a recipe, which I think is a little beyond `gcc -M`'s scope.
Thanks for bringing up the pattern rule workaround, though. That's something I didn't know. (I'm not super familiar with Make!) I'll see what can be done. But generally, I try to avoid the problem, because a workaround here could be a trouble elsewhere. And compiling a CMI is relatively fast, so one-or-zero time of occasionally recompiling a CMI, compared to other problems that need to be fixed, is tolerable to me. Of course, if you have any good idea, please do share it. And yes, Fortran module resonates quite a lot with C++ modules. I'll be reading about it. On Friday, February 28th, 2025 at 23:59, NightStrike via Gcc <gcc@gcc.gnu.org> wrote: > On Thu, Feb 27, 2025 at 21:39 vspefs via Gcc gcc@gcc.gnu.org wrote: > > > Current `-Mmodules` output is based on 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. > > > > 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. > > > > An example project can be found here. > > > > 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.
