On Fri, Feb 28, 2025 at 07:59:00 -0800, NightStrike via Gcc wrote: > Could your approach simultaneously be used to have better dependency > information for Fortran modules? I feel like there’s at least some overlap > there.
P1689 is also intended to be suitable for Fortran (CMake uses it for its Fortran dependency scanning internally). I'd like to integrate it into gfortran as well, but not had the time to do so. > 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. Yes, the basic features are the same. Note that one thing that is missing is ninja's `restat = 1` feature. This "restats" the output for the associated rule (probably spelled `.RESTAT: output` in Make) and skips running dependent rules if the output has not updated the mtime of the output(s) before the rule (recipe) was executed. This can be used for modules to not have to recompile sources that import the output modules it if they didn't change (e.g., a typo was fixed in an unexported function body). --Ben
