Alan W. Irwin wrote: > I should also mention that for the simple example I attached to the > previous > e-mail the gfortran library build does produce a valid module file called > hello_module.mod. > > So it appears bug 3984 is just caused by CMake assuming the module file > name > is MODULENAME.mod.proxy rather than the correct MODULENAME.mod (where > MODULENAME is hello_module in the particular case of the simple example I > gave of bug 3984 in action). > > Does anybody know why cmake appends ".proxy" to the file that it thinks > will > satisfy the module dependency? Perhaps there is a valid reason for > appending ".proxy" to the real name of the module file, but if that is so > the CMake developers forgot to take the final step of associating the > MODULENAME.mod.proxy name with the actual real name of the module file > produced by fortran compilers.
Years ago I designed a makefile layout that handled everything correctly. I had it mostly working in cmLocalMakefileGenerator2 which was an unreleased intermediate development makefile generator that preceded cmLocalMakefileGenerator3 (the current makefile generator). When the implementation was converted to the newer makefile generator by another developer it was not done quite right and I've never had time to go back and fix it. The basic problem for building fortran9x code that uses modules with a makefile system is that some sources have to be brought up to date before a make tool even considers the dependencies of other sources. It actually requires recursive make calls. IIRC, the .proxy target is not meant to ever be a file but just a symbolic make target. The idea is to say "I need whomever provides this module to be brought up to date before make even looks at me" by depending on the .proxy name of the module. Any source that provides a module creates a dependency from the .proxy name to itself. All these symbolic targets are evaluated to choose in what order to run make processes to evaluated file-level dependencies for the actual sources and object files. The other problem is that the preprocessor must be run in order to check module-level dependencies since #ifdef can be used to decide whether to use a module. Technically this should be done for C and C++ too, but it would make dependency scanning far slower. If a few #include lines are included in the dependency check when they shouldn't in C/C++ it just adds an extra dependency that doesn't really hurt. The problem for Fortran is that the extra dependency can actually break the build. I'll be glad to help anyone interested in trying to fix any of this get started. -Brad _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
