[cmake-developers] Fortran support for Ninja generator

[Brad King]

On 03/24/2015 05:46 AM, Nils Gladitz wrote:
>> One mention was to use the -M* flags supported by gfortran, just as
>> with gcc. However, when I tried this approach I found out that the -M*
>> flag for gfortran seems buggy, it doesn't output the correct format
>> (e.g. the target given with -MT flag is just added instead of
>> overwriting the default target). So, my ninja build failed saying the
>> depfile format was wrong.

Yes, gfortran seems to produce rules with multiple outputs and ninja
expects there to be only one output.  It looks like gfortran lists the
module.mod files produced by a translation unit as outputs and those
consumed by a translation unit as dependencies.  This is valuable
information for ordering compilations, but we need to figure out the
right way to get ninja to use the information.  In particular, we
need to get the information before a rule runs.

>> Alternatively someone proposed to have ninja use cmake-generated
>> dependencies.
> 
> I am not very familiar with fortran myself but there was this discussion 
> on the ninja mailing list that implied that this might also require 
> changes to ninja itself:
> 
> https://groups.google.com/d/msg/ninja-build/b1-AF3pRJuE/NkPDsO0C2IUJ

That discussion concludes assuming that CMake scans source files
while generating the build files to generate the ordering dependencies.
It does not.  There could be generated source files or header files
that are needed to get the ordering right.  In the Makefile generator
we have a step to scan dependencies for a target after all its
dependencies are finished and its custom commands have executed.
This ensures generated files are available.  Then CMake puts the
dependency scanning results in a place used by the actual compile
and link rules.

There is absolutely no way to do this without some kind of change
to ninja because its build plan graph must be updated dynamically
to add Fortran module dependencies as they are discovered.  AFAIK
the only place ninja has for dynamically updating the build plan
is the restat=1 option.  IIUC the depfile information is loaded
only at the beginning of the build.  The "deps=gcc" option causes
it to read a depfile immediately after a rule produces it, but
I'm not sure whether it only transfers the information to the
.ninja_deps file or updates its build graph on the fly.  In all
of these cases the build plan updates affecting a rule only occur
*after* it runs.  We cannot pre-generate a depfile because there
is not enough information to do so until during the build.

I've been thinking about some ideas on how build.ninja rules
could express the dynamic scanning and update we need.  Rather
than posting them now, perhaps the design process would benefit
from any independently developed ideas you may have.

Thanks,
-Brad