The author says Fortran modules are easier for build systems to handle:
'A Ninja file is static, thus we need to know a) the compilation arguments to use and b) interdependencies between files. The latter can't be done for things like Fortran or C++ modules. This is why Ninja has a functionality called dyndeps. It is a way to call an external program that scans the sources to be built and then writes a simple Makefile-esque snippet describing which order things should be built in. This is a simple and understandable step that works nicely for Fortran modules but is by itself insufficient for C++ modules.'
...
'Let's start by listing the requirements [for modules]:
All command lines used must be knowable a priori, that is, without scanning the contents of source files
Any compiler may choose to name its module files however it wants, but said mapping must be knowable just from the compiler name and version, i.o.w. it has to be documented
Changing source files must not cause, by itself, a reconfiguration, only a rescan for deps followed by a build of the changed files
The developer must not need to tell which sources are which module types in the build system, it is to be deduced automatically without needing to scan the contents of source files (i.e. by using the proper file extension)
Module files are per-compiler and per-version and only make sense within the build tree of a single project
If module files are to be installed, those are defined in a way that does not affect source files with modules that do not need installing.
Fortran modules are great for developers but a bit of a pain when setting up a build system (even though it’s quite straightforward now, it still requires a first pass with something like makedepf90 or one of its many equivalents). I find it quite a feat that C++ modules, while benefitting from the experience of many languages, ended up so broken.
Also, I never really liked cmake but this looks really bad.
If your language has modules, like in the syntax and semantics, and you're still requiring external tools to hunt down dependencies, your module system must somehow be a failure.
The idea behind modules is that since they are part of the language, the compiler for the language understands modules and follows the dependencies. All module-related tooling, like incremental builds, is hooked through the compiler. You don't use make or external dependency generators.
If someone does need a dependency generator for whatever reason, the compiler has to provide that function. You give the compiler the proper option to spit out dependencies, point it at the root module of the program, and let it do its thing.
> If your language has modules, like in the syntax and semantics, and you're still requiring external tools to hunt down dependencies, your module system must somehow be a failure.
No argument from me :)
> The idea behind modules is that since they are part of the language, the compiler for the language understands modules and follows the dependencies. All module-related tooling, like incremental builds, is hooked through the compiler.
I am not sure I follow. The compiler still compiles one file each time it is run, so we need a first pass to determine the dependency tree and what can be compiled in which order, right? Even if that first pass uses the compiler itself (doing only enough parsing to see what is needed).
> You give the compiler the proper option to spit out dependencies, point it at the root module of the program, and let it do its thing.
Nowadays, gfortran can generate Makefile fragments with the dependencies, but it was not always the case. This is why there are a handful of small tools to do it and makedepf90 is one of them (it’s a small Fortran program with a rudimentary parser). There are also other compilers that don’t do it properly.
'A Ninja file is static, thus we need to know a) the compilation arguments to use and b) interdependencies between files. The latter can't be done for things like Fortran or C++ modules. This is why Ninja has a functionality called dyndeps. It is a way to call an external program that scans the sources to be built and then writes a simple Makefile-esque snippet describing which order things should be built in. This is a simple and understandable step that works nicely for Fortran modules but is by itself insufficient for C++ modules.'
...
'Let's start by listing the requirements [for modules]:
All command lines used must be knowable a priori, that is, without scanning the contents of source files
Any compiler may choose to name its module files however it wants, but said mapping must be knowable just from the compiler name and version, i.o.w. it has to be documented
Changing source files must not cause, by itself, a reconfiguration, only a rescan for deps followed by a build of the changed files
The developer must not need to tell which sources are which module types in the build system, it is to be deduced automatically without needing to scan the contents of source files (i.e. by using the proper file extension)
Module files are per-compiler and per-version and only make sense within the build tree of a single project
If module files are to be installed, those are defined in a way that does not affect source files with modules that do not need installing.
Fortran modules already satisfy all of these.'