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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
