(0005572)
Bill Hoffman (manager)
2006-10-27 10:42

The url seems to be missing? Can you create an attachment with a tar file that shows the problem?

(0005573)
irwin (reporter)
2006-10-27 10:51

I just clicked on the URL and it worked fine; i.e. it found the page at http://www.cmake.org/pipermail/cmake/2006-October/011728.html [^] which has a complete description of the problem including the three small files needed to generate it.

(0005574)
irwin (reporter)
2006-10-27 10:59

To make this bug report more self-contained I have just attached a file with the complete description of the problem which is also referenced by the URL

(0005575)
Bill Hoffman (manager)
2006-10-27 11:21

Can you try putting the two sources in the same target?

add_executable(hello_program hello.f90 hello_program.f90)

Just comment out the add_library. Does that work?

(0005579)
irwin (reporter)
2006-10-27 12:10

To be specific here is the latest CMakeLists.txt that implements the desired test.

project(test)
enable_language(Fortran)
add_executable(hello_program hello_program.f90 hello.f90)

The answer to the question is yes, putting all the sources in the same target works fine as expected. The dependency issue for fortran 95 modules only occurs if you have separate executable and library targets with dependencies between them as in my original simple test.

(0005775)
irwin (reporter)
2006-11-23 12:07

This significant fortran 95 module dependency issue still exists for CMake 2.4.4.

(0009299)
ufnoise (reporter)
2007-09-26 10:46

I've found that any comment line in fortran with the word use in it triggers the dependency scanner to look for the mod file named after the next word. Can the "use" parser be made any smarter?

For example this code:

c Modified: Michael Eldredge -- Stanford (oct 87)
c convert to use new GENII

triggers:

make[2]: *** No rule to make target `new.mod.proxy', needed by `src/CMakeFiles/pisces.dir/filopncls.o.requires'. Stop.
make[1]: *** [src/CMakeFiles/pisces.dir/all] Error 2
make: *** [all] Error 2

but this code does not:
c Modified: Michael Eldredge -- Stanford (oct 87)
c convert to xuse new GENII

(0009300)
irwin (reporter)
2007-09-26 12:25

Actually, that "use" problem for lines starting with "c" is bug 3109 which
has similar symptoms to the current bug 3984, but very different cause.

What's going on for 3109 is lines beginning with "c" are parsed rather than ignored so that any use of "use" in those lines convinces cmake there is a fortran module which the code depends on, and it crashes when it doesn't find that module.

What's going on for the current bug 3984 is "use MODULENAME" is actually part of a fortran statement; there really is a module that the code depends on called MODULENAME.mod. But cmake fails with that case as well because it is looking for MODULENAME.mod.proxy rather than the correct name, MODULENAME.mod. The only (ugly) workaround is to create a file with arbitrary contents (or empty) called MODULENAME.mod.proxy at cmake time to convince cmake that the dependency has been satisfied at build time.

(0009347)
Brad King (manager)
2007-10-01 11:56

MODULENAME.mod.proxy is the correct name on which to depend. The problem is that the .proxy rules are not getting connected together properly across targets. My original design for the Fortran module dependencies was created in a previous Makefile generator that had all targets in one directory going into a single makefile. When CMake was updated to use a separate build.make for each target the Fortran module support across targets was broken.

Connecting these rules together across targets will not be trivial. It will have to create inter-target dependencies that are present only because of the module provides/requires relationship between two sources inside the target. I do not know when I will be able to get to this.

(0009376)
Brad King (manager)
2007-10-03 16:22

The following commit should fix this in CMake HEAD:

/cvsroot/CMake/CMake/Source/cmDependsFortran.cxx,v <-- cmDependsFortran.cxx
new revision: 1.22; previous revision: 1.21

Since the library is linked by the executable, the whole target will be updated before the executable target is built. Therefore the module will always be up to date before considering the requirement. The .mod.proxy dependency in the executable basically says "if any object *in this target* provides this module please build before evaluating my file-level dependencies.". The above change adds the statement "if no object in this target provides the module that is okay...we'll assume another target provided it".

(0009377)
Brad King (manager)
2007-10-03 16:23

Automatic inter-target dependencies created implicitly by module dependencies in sources is far too complicated to implement now. The use case mentioned in this bug already has the necessary inter-target dependency. The fix just noted is sufficient to close this bug.

Issue History
Date Modified	Username	Field	Change
2007-09-26 10:46	ufnoise	Note Added: 0009299
2007-09-26 12:25	irwin	Note Added: 0009300
2007-10-01 11:56	Brad King	Note Added: 0009347
2007-10-03 15:48	Brad King	Relationship added	related to 0005809
2007-10-03 16:22	Brad King	Note Added: 0009376
2007-10-03 16:23	Brad King	Status	assigned => closed
2007-10-03 16:23	Brad King	Note Added: 0009377
2007-10-03 16:23	Brad King	Resolution	open => fixed

Notes
(0005572) Bill Hoffman (manager) 2006-10-27 10:42	The url seems to be missing? Can you create an attachment with a tar file that shows the problem?

(0005573) irwin (reporter) 2006-10-27 10:51	I just clicked on the URL and it worked fine; i.e. it found the page at http://www.cmake.org/pipermail/cmake/2006-October/011728.html [^] which has a complete description of the problem including the three small files needed to generate it.

(0005574) irwin (reporter) 2006-10-27 10:59	To make this bug report more self-contained I have just attached a file with the complete description of the problem which is also referenced by the URL

(0005575) Bill Hoffman (manager) 2006-10-27 11:21	Can you try putting the two sources in the same target? add_executable(hello_program hello.f90 hello_program.f90) Just comment out the add_library. Does that work?

(0005579) irwin (reporter) 2006-10-27 12:10	To be specific here is the latest CMakeLists.txt that implements the desired test. project(test) enable_language(Fortran) add_executable(hello_program hello_program.f90 hello.f90) The answer to the question is yes, putting all the sources in the same target works fine as expected. The dependency issue for fortran 95 modules only occurs if you have separate executable and library targets with dependencies between them as in my original simple test.

(0005775) irwin (reporter) 2006-11-23 12:07	This significant fortran 95 module dependency issue still exists for CMake 2.4.4.

(0009299) ufnoise (reporter) 2007-09-26 10:46	I've found that any comment line in fortran with the word use in it triggers the dependency scanner to look for the mod file named after the next word. Can the "use" parser be made any smarter? For example this code: c Modified: Michael Eldredge -- Stanford (oct 87) c convert to use new GENII triggers: make[2]: * No rule to make target `new.mod.proxy', needed by `src/CMakeFiles/pisces.dir/filopncls.o.requires'. Stop. make[1]: * [src/CMakeFiles/pisces.dir/all] Error 2 make: *** [all] Error 2 but this code does not: c Modified: Michael Eldredge -- Stanford (oct 87) c convert to xuse new GENII

(0009300) irwin (reporter) 2007-09-26 12:25	Actually, that "use" problem for lines starting with "c" is bug 3109 which has similar symptoms to the current bug 3984, but very different cause. What's going on for 3109 is lines beginning with "c" are parsed rather than ignored so that any use of "use" in those lines convinces cmake there is a fortran module which the code depends on, and it crashes when it doesn't find that module. What's going on for the current bug 3984 is "use MODULENAME" is actually part of a fortran statement; there really is a module that the code depends on called MODULENAME.mod. But cmake fails with that case as well because it is looking for MODULENAME.mod.proxy rather than the correct name, MODULENAME.mod. The only (ugly) workaround is to create a file with arbitrary contents (or empty) called MODULENAME.mod.proxy at cmake time to convince cmake that the dependency has been satisfied at build time.

(0009347) Brad King (manager) 2007-10-01 11:56	MODULENAME.mod.proxy is the correct name on which to depend. The problem is that the .proxy rules are not getting connected together properly across targets. My original design for the Fortran module dependencies was created in a previous Makefile generator that had all targets in one directory going into a single makefile. When CMake was updated to use a separate build.make for each target the Fortran module support across targets was broken. Connecting these rules together across targets will not be trivial. It will have to create inter-target dependencies that are present only because of the module provides/requires relationship between two sources inside the target. I do not know when I will be able to get to this.

(0009376) Brad King (manager) 2007-10-03 16:22	The following commit should fix this in CMake HEAD: /cvsroot/CMake/CMake/Source/cmDependsFortran.cxx,v <-- cmDependsFortran.cxx new revision: 1.22; previous revision: 1.21 Since the library is linked by the executable, the whole target will be updated before the executable target is built. Therefore the module will always be up to date before considering the requirement. The .mod.proxy dependency in the executable basically says "if any object in this target provides this module please build before evaluating my file-level dependencies.". The above change adds the statement "if no object in this target provides the module that is okay...we'll assume another target provided it".

(0009377) Brad King (manager) 2007-10-03 16:23	Automatic inter-target dependencies created implicitly by module dependencies in sources is far too complicated to implement now. The use case mentioned in this bug already has the necessary inter-target dependency. The fix just noted is sufficient to close this bug.