MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005809CMakeCMakepublic2007-10-01 05:252012-08-15 08:22
ReporterMaik Beckmann 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005809: Fortran 77/9x support enhancements
DescriptionCMake doesn't offer full support for Fortran 77/95. This bug-report wants a place for patches and discussions on this issue.
Steps To Reproduce
Additional InformationThings that should work are...

  1. comments in fixed-format can contain the "use" keyword.
     (see: http://www.cmake.org/Wiki/CMake_FAQ#CMake_dependency_scanner [^])
    
     example:
    <main.f>
      PROGRAM hello
C USE foo
      IMPLICIT NONE

      WRITE(*,*) 'Hello, Fortran world.'
      END PROGRAM
    </main.f>
    <CMakeLists.txt>
project(test Fortran)

add_executable(main main.f)
    </CMakeLists.txt>

  *status:
    fixed! I updated the makedepf90-2.8.8 lex/yacc parser, which solved this
        issue, to CMake-2.4.7 .
    CMake-HEAD: I will look into the HEAD version of CMake if there related
        sources are changed until 2.4.7 . If so I will prepare a new patch.
                
TagsNo tags attached.
Relationships
related to 0003109closed Brad King Fortran dependancy checker does not ignore comments 
related to 0003195closed Brad King depend.make has incorrect f90 dependencies for USE 
related to 0003984closed Brad King A fortran 95 module dependency issue 
related to 0002361closed Brad King FORTRAN 9x module dependencies parsing 
related to 0003144closed Brad King cmake fails when fortran modules are saved in an otehr directory that the default one. 
related to 0013471closed Brad King CMake does not understand Fortran interface "module procedure" syntax 
Attached Filespatch makedepf90-2.8.8_port_cm-2.4.7.patch (14,921) 2007-10-01 05:25
https://public.kitware.com/Bug/file/1160/makedepf90-2.8.8_port_cm-2.4.7.patch
gz lib_dep_example.tar.gz (527) 2007-10-01 06:37
https://public.kitware.com/Bug/file/1161/lib_dep_example.tar.gz
gz missing_mod_dep.tar.gz (318) 2007-10-01 14:46
https://public.kitware.com/Bug/file/1162/missing_mod_dep.tar.gz
patch test_use_in_comment.patch (1,337) 2007-10-06 15:23
https://public.kitware.com/Bug/file/1167/test_use_in_comment.patch
gz example_simpleProgram.tar.gz (541) 2007-10-08 08:24
https://public.kitware.com/Bug/file/1168/example_simpleProgram.tar.gz
gz examples_using_Makefiles.tar.gz (4,189) 2007-10-08 10:41
https://public.kitware.com/Bug/file/1169/examples_using_Makefiles.tar.gz
patch in_interface.patch (669) 2007-10-09 13:49
https://public.kitware.com/Bug/file/1172/in_interface.patch
? in_interface.patch2 (643) 2007-10-10 02:04
https://public.kitware.com/Bug/file/1174/in_interface.patch2
patch Tests_Fortran.patch (2,268) 2007-10-10 07:14
https://public.kitware.com/Bug/file/1175/Tests_Fortran.patch
patch conservative_full_fortran_support_rev0.patch (44,113) 2007-12-22 18:55
https://public.kitware.com/Bug/file/1270/conservative_full_fortran_support_rev0.patch
patch full_fortran_support_rev0.patch (43,671) 2007-12-23 13:56
https://public.kitware.com/Bug/file/1271/full_fortran_support_rev0.patch
gz testcases_rev0.tar.gz (2,365) 2007-12-23 13:59
https://public.kitware.com/Bug/file/1272/testcases_rev0.tar.gz
Issue History
Date ModifiedUsernameFieldChange
2007-10-01 05:25Maik BeckmannNew Issue
2007-10-01 05:25Maik BeckmannFile Added: makedepf90-2.8.8_port_cm-2.4.7.patch
2007-10-01 06:19Maik BeckmannNote Added: 0009341
2007-10-01 06:36Maik BeckmannNote Added: 0009342
2007-10-01 06:37Maik BeckmannFile Added: lib_dep_example.tar.gz
2007-10-01 11:46Wim Van HoydonckNote Added: 0009346
2007-10-01 14:45Maik BeckmannNote Added: 0009351
2007-10-01 14:46Maik BeckmannFile Added: missing_mod_dep.tar.gz
2007-10-01 17:38irwinNote Added: 0009352
2007-10-02 02:56Maik BeckmannNote Added: 0009360
2007-10-02 02:59Maik BeckmannNote Edited: 0009360
2007-10-03 14:59Bill HoffmanAssigned To => Brad King
2007-10-03 14:59Bill HoffmanStatusnew => assigned
2007-10-03 15:42Brad KingNote Added: 0009372
2007-10-03 15:44Brad KingNote Added: 0009373
2007-10-03 15:46Brad KingRelationship addedrelated to 0003109
2007-10-03 15:48Brad KingRelationship addedrelated to 0003195
2007-10-03 15:48Brad KingRelationship addedrelated to 0003984
2007-10-03 15:49Brad KingRelationship addedrelated to 0002361
2007-10-03 15:53Brad KingNote Added: 0009374
2007-10-03 16:26Brad KingNote Added: 0009378
2007-10-03 16:28Brad KingRelationship addedrelated to 0003144
2007-10-03 16:30Brad KingNote Added: 0009379
2007-10-03 17:04Brad KingNote Added: 0009380
2007-10-03 17:08irwinNote Added: 0009381
2007-10-04 01:16Maik BeckmannNote Added: 0009383
2007-10-04 05:40Maik BeckmannNote Edited: 0009383
2007-10-04 09:43Brad KingNote Added: 0009384
2007-10-06 15:23Maik BeckmannFile Added: test_use_in_comment.patch
2007-10-06 15:25Maik BeckmannNote Added: 0009395
2007-10-06 16:44Maik BeckmannNote Edited: 0009395
2007-10-08 08:24Maik BeckmannFile Added: example_simpleProgram.tar.gz
2007-10-08 10:41Maik BeckmannFile Added: examples_using_Makefiles.tar.gz
2007-10-08 10:52Maik BeckmannNote Added: 0009401
2007-10-08 11:46Maik BeckmannNote Edited: 0009401
2007-10-08 12:19irwinNote Added: 0009402
2007-10-09 13:48Maik BeckmannNote Added: 0009407
2007-10-09 13:49Maik BeckmannFile Added: in_interface.patch
2007-10-10 02:03Maik BeckmannNote Edited: 0009407
2007-10-10 02:04Maik BeckmannFile Added: in_interface.patch2
2007-10-10 02:04Maik BeckmannNote Edited: 0009407
2007-10-10 07:14Maik BeckmannFile Added: Tests_Fortran.patch
2007-10-10 07:14Maik BeckmannNote Deleted: 0009395
2007-10-10 07:19Maik BeckmannNote Added: 0009408
2007-10-10 09:09Brad KingNote Added: 0009410
2007-10-10 09:10Brad KingNote Added: 0009411
2007-10-10 09:18Brad KingNote Added: 0009412
2007-10-12 09:53Brad KingNote Added: 0009426
2007-12-22 18:55Maik BeckmannFile Added: conservative_full_fortran_support_rev0.patch
2007-12-22 19:04Maik BeckmannNote Added: 0010015
2007-12-23 13:56Maik BeckmannNote Added: 0010016
2007-12-23 13:56Maik BeckmannFile Added: full_fortran_support_rev0.patch
2007-12-23 13:59Maik BeckmannNote Added: 0010017
2007-12-23 13:59Maik BeckmannFile Added: testcases_rev0.tar.gz
2007-12-23 14:12Maik BeckmannNote Added: 0010018
2007-12-28 11:55Brad KingNote Added: 0010029
2007-12-30 16:17Brad KingNote Added: 0010033
2007-12-31 11:27Brad KingNote Added: 0010035
2007-12-31 13:12Maik BeckmannNote Added: 0010036
2008-01-15 21:09Brad KingStatusassigned => closed
2008-01-15 21:09Brad KingNote Added: 0010159
2008-01-15 21:09Brad KingResolutionopen => fixed
2012-08-15 08:22Brad KingRelationship addedrelated to 0013471

Notes
(0009341)
Maik Beckmann   
2007-10-01 06:19   
makedepf90-2.8.8_port_cm-2.4.7.patch works on current HEAD too.

Maik
(0009342)
Maik Beckmann   
2007-10-01 06:36   
Things that should work...

2. build an executable which depends on a Fortran 95 library
   (see: http://www.cmake.org/Bug/view.php?id=3984 [^])

    status: This is is the next issue I'll working on.
        A minimal example which actually is the one provided by Alan in bug
        0003984 is attached.
        The module is created correctly by the compiler, but the the
        Makefile which build the executable target doesn't know this.
        This seems to be caused by the limitation of the current source
        parsing strategy, which does all the work per source-file. Thus
        CMake can't determine if an USEed module is provided by a sourcefile
        off the same target or not.

        I'll investigate.

Maik
(0009346)
Wim Van Hoydonck   
2007-10-01 11:46   
http://www.cmake.org/Bug/view.php?id=5645 [^] (This is specific for the intel fortran compiler on linux.)

cmake/Modules/Platform/Linux-ifort.cmake: SET(CMAKE_SHARED_LIBRARY_Fortran_FLAGS "-KPIC") does not work with ifort version 10.

ifort: command line remark 10148: option '-K' not supported

Could this be changed to SET(CMAKE_SHARED_LIBRARY_Fortran_FLAGS "-fPIC")?
(0009351)
Maik Beckmann   
2007-10-01 14:45   
I found out that CMake doesn't rebuild fortran 9x proper.

To see this behavior see missing_mod_dep.tar.gz. It contains a CMakeLists.txt
and the two fortran source-files main.f90 and a.f90. a.f90 provides a module named X. main.f90 contains a program which uses module X.

Everything builds fine. But if a.f90 is changed while coding main.f90 has to be recompiled too. This doesn't happen!

Modules produce the dependencies as includes does. The only difference is that you can't just scan the filesystem if a "use ModName" is found, all other source files have to be scanned for "module ModName".

Maik
(0009352)
irwin   
2007-10-01 17:38   
Interesting note recently added by Brad King to bug 3984 and transcribed here by AWI.

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.
(0009360)
Maik Beckmann   
2007-10-02 02:56   
(edited on: 2007-10-02 02:59)
Thanks to Alan for starting this wiki page:
    - http://www.cmake.org/Wiki/CMake_Fortran_Issues [^]

I propose to use the wiki to collect and comment the topics, like
    1. comments in fixed-format can contain the "use" keyword.
      ....
      status:
          ....
    2. build an executable which depends on a Fortran 95 library
       ...
and to maintain design blueprints for things like non trival changes to make mod.poxy depend proper on each other.

All in all the wiki should be the place where the extract of discussions made at this bug report resides.

Everything else, especially files like patches, zipped examples and notes on them, should reside at this bug report.


Maik
(0009372)
Brad King   
2007-10-03 15:42   
I've applied the makedepf90-2.8.8_port_cm-2.4.7.patch to the development HEAD of CMake:

/cvsroot/CMake/CMake/Source/cmDependsFortran.cxx,v <-- cmDependsFortran.cxx
new revision: 1.21; previous revision: 1.20
/cvsroot/CMake/CMake/Source/cmDependsFortranLexer.cxx,v <-- cmDependsFortranLexer.cxx
new revision: 1.10; previous revision: 1.9
/cvsroot/CMake/CMake/Source/cmDependsFortranLexer.h,v <-- cmDependsFortranLexer.h
new revision: 1.7; previous revision: 1.6
/cvsroot/CMake/CMake/Source/cmDependsFortranLexer.in.l,v <-- cmDependsFortranLexer.in.l
new revision: 1.10; previous revision: 1.9
/cvsroot/CMake/CMake/Source/cmDependsFortranParser.cxx,v <-- cmDependsFortranParser.cxx
new revision: 1.8; previous revision: 1.7
/cvsroot/CMake/CMake/Source/cmDependsFortranParser.h,v <-- cmDependsFortranParser.h
new revision: 1.4; previous revision: 1.3
/cvsroot/CMake/CMake/Source/cmDependsFortranParser.y,v <-- cmDependsFortranParser.y
new revision: 1.12; previous revision: 1.11
/cvsroot/CMake/CMake/Source/cmDependsFortranParserTokens.h,v <-- cmDependsFortranParserTokens.h
new revision: 1.5; previous revision: 1.4

The commit includes the updated pre-generated lexer/parser sources.
(0009373)
Brad King   
2007-10-03 15:44   
Maik, would you please submit a patch for Tests/Fortran to test the "use" bug? The test should fail with cmake 2.4.7 by giving the unknown module error. It should pass with cmake HEAD. Thanks.
(0009374)
Brad King   
2007-10-03 15:53   
Bug 0002361 also points out that the preprocessor macros are not taken into account when scanning for "use" lines. This may result in bogus dependencies on modules that do not exist.

It looks like Maik's patch has the start of fixing this with the "InPPFalseBranch" member that is not set or used yet.
(0009378)
Brad King   
2007-10-03 16:26   
Update on issues in this bug:

Bug 3195 has been closed as a duplicate of bug 3109.
Bug 3109 has been closed by fixing the problem with the patch supplied in this bug.
Bug 3984 has been closed by fixing it with another simple change.

Bug 2361 is still open because it requests handling of preprocessor macros during dependency scanning.
(0009379)
Brad King   
2007-10-03 16:30   
I've linked bug 0003144 to this bug because it also deals with modules. It requests support for modules in a separate directory from the build tree (such as with the -modules flag of the intel compiler).
(0009380)
Brad King   
2007-10-03 17:04   
Fixes to previously applied patch to compile without strcasecmp:

/cvsroot/CMake/CMake/Source/cmDependsFortranParser.cxx,v <-- cmDependsFortranParser.cxx
new revision: 1.9; previous revision: 1.8
/cvsroot/CMake/CMake/Source/cmDependsFortranParser.y,v <-- cmDependsFortranParser.y
new revision: 1.13; previous revision: 1.12
(0009381)
irwin   
2007-10-03 17:08   
Here is Brad's final comment when he closed 3984:

"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."

My interpretation of the fix comment and Brad's close comment above is that inter-target _Fortran module_ dependencies are now completely ignored, but that will normally not be an issue since an executable that depends on a fortran library already has the normal dependency on that library and adding an additional dependency on the module automatically created when the library was built doesn't gain you anything.

Assuming my interpretation is correct (and please correct in a note here, Brad, if I got something wrong), I think that is an excellent way to deal with this issue, and I am looking forward to testing out cmake CVS HEAD in this regard and also with regard to the parsing bug just fixed in cmake CVS.

Note the test is going to take some time to implement since there are a number of horrible cmake workarounds I have to remove temporarily from e.g., PLplot and FreeEOS to do proper tests of the recent changes.
(0009383)
Maik Beckmann   
2007-10-04 01:16   
(edited on: 2007-10-04 05:40)
At Saturday I'll have time to continue on CMake.

The "InPPFalseBranch" stuff was indeed introduced for taking preprocessor defines into account. But this issue is at the very bottom of my personal TODO list. The most important things are IMHO
    1. build a f9x target without external modules (works)
    2. fix the makefile generation to fix recompilation order (doesn't work)
    3. build a f9x target with external modules (doesn't work)
    4. build a f9x exe-target which depends on a f9x lib-target which in
       turn provides modules used by the exe-target. (doesn't work)
    
Maik

PS: Test for the "use" issue will be provided
(0009384)
Brad King   
2007-10-04 09:43   
Maik, when you continue work please be sure to work on CMake HEAD, not on 2.4.x. Yesterday I closed bug 0003984 which should take care of your 4th item.

Thanks for your work!
(0009401)
Maik Beckmann   
2007-10-08 10:52   
(edited on: 2007-10-08 11:46)
Hello,

I put some content to http://www.cmake.org/Wiki/CMake_Fortran_Issues. [^] I tried to point out the problems of the current CMake implementation by showing Makefiles which behave like the ones CMake actually generates. Additionally for each example a set of alternative Makefiles is provided to show what could be possible to respect the dependencies right. Finally I gave a conclusion about what can be done to make CMake able to handle module dependencies right.

The comments on each example are spare, I will add more when I got more time.

I'm sure there are many odd English phrases, feel free to correct them if you're sure you know what I meant.

Best Regards,
Maik
(0009402)
irwin   
2007-10-08 12:19   
Hi Maik,

I think your effort is a good idea to help clarify the issues.

I have done some light editing of the language of http://www.cmake.org/Wiki/CMake_Fortran_Issues [^] without intruding on technical issues.

Brad, I hope you will take a look at the technical issues.
(0009407)
Maik Beckmann   
2007-10-09 13:48   
(edited on: 2007-10-10 02:04)
There is a little bug that causes the current parser not to respect InModule state
    http://article.gmane.org/gmane.comp.programming.tools.cmake.user/8916 [^]

in_interface.patch2 fixes it. (ignore in_interface.patch)

Brad, please ignore the test_use_in_comment patch. I will upload a patch which superseeds it by adding an "in inteface" test, plus moving the module test inside
IF(CMAKE_Fortran_COMPILER_SUPPORTS_F90)...ENDIF(..)

Maik
(0009408)
Maik Beckmann   
2007-10-10 07:19   
Tests_Fortran.patch adds Tests for
   - use keyword in comment
   - module keyword in interface

Maik

PS: Is it able to delete or mark uploaded files as obsolete?
(0009410)
Brad King   
2007-10-10 09:09   
I've applied in_interface.patch2.

/cvsroot/CMake/CMake/Source/cmDependsFortran.cxx,v <-- cmDependsFortran.cxx
new revision: 1.23; previous revision: 1.22
(0009411)
Brad King   
2007-10-10 09:10   
I've applied Tests_Fortran.patch:

/cvsroot/CMake/CMake/Tests/Fortran/CMakeLists.txt,v <-- CMakeLists.txt
new revision: 1.8; previous revision: 1.7
/cvsroot/CMake/CMake/Tests/Fortran/test_use_in_comment_fixedform.f,v <-- test_use_in_comment_fixedform.f
initial revision: 1.1
/cvsroot/CMake/CMake/Tests/Fortran/test_use_in_comment_freeform.f90,v <-- test_use_in_comment_freeform.f90
initial revision: 1.1
/cvsroot/CMake/CMake/Tests/Fortran/in_interface/main.f90,v <-- main.f90
initial revision: 1.1
/cvsroot/CMake/CMake/Tests/Fortran/in_interface/module.f90,v <-- module.f90
initial revision: 1.1
(0009412)
Brad King   
2007-10-10 09:18   
Irwin, thanks for writing out the problems on the Wiki. The annoying thing is that I had that all working in "cmLocalUnixMakefileGenerator2.cxx" several years ago (proper rebuilds with modules and all). That was never released, and code was moved to the current 3rd-generation Makefile generator. The fortran support was not properly converted and I never had time to go back and fix it.

I'll get to these issues when I can.
(0009426)
Brad King   
2007-10-12 09:53   
I've just committed these changes:

/cvsroot/CMake/CMake/Source/cmDependsFortran.cxx,v <-- cmDependsFortran.cxx
new revision: 1.24; previous revision: 1.23
/cvsroot/CMake/CMake/Source/cmLocalUnixMakefileGenerator3.cxx,v <-- cmLocalUnixMakefileGenerator3.cxx
new revision: 1.217; previous revision: 1.216

They add the dependency from an object file to the timestamp files for the modules it requires. Dummy timestamp files are created in case nothing actually provides them. This fixes rebuilding of object files whose required modules are provided by another object in the same directory.

A separate mechanism will be needed to locate modules provided in other directories or outside the project and update the local target's module timestamp files appropriately.
(0010015)
Maik Beckmann   
2007-12-22 19:04   
conservative_full_fortran_support_rev0.patch:

This patch wants to add full support for fortran including module dependencies.

It's called conservative because it adds an extra global step to scan all Fortran Sources before any other dependency generation is done. In the future this will be replaced by an pure per target strategy.

It's the very first draft, so don't use it for any reasonable things!

Please test it and report problem via email to
  maikbeckmann <at> gmx <dot> de

-- Maik
(0010016)
Maik Beckmann   
2007-12-23 13:56   
Please _ignore_ conservative_full_fortran_support_rev0.patch

 -- Maik
(0010017)
Maik Beckmann   
2007-12-23 13:59   
full_fortran_support_rev0.patch:

This patch wants to add full support for fortran including module dependencies.

It's an early draft, so don't use it for any reasonable things!

Please test it and report problem via email to
  maikbeckmann <at> gmx <dot> de

-- Maik
(0010018)
Maik Beckmann   
2007-12-23 14:12   
testcases_rev0.tar.gz:

This tarball includes a number of fortran projects which should work proper compiled and link regardless in what order one alters their source files.

At the moment a project which has multiple target within the same CMakeLists.txt sharing at least one source file which provides a module compiles and links more times than necessary. This happens because the corresponding .mod files is altered by the compiler each time the shared source is compiled for an target. See "same_source_multiple_targets" is an example of such a project.

Everything else works fine.

 -- Maik
(0010029)
Brad King   
2007-12-28 11:55   
I've implemented module dependency support across directories and on external modules found in the include path. Thanks alot to Maik for design discussions and test cases.

Main implementation:

/cvsroot/CMake/CMake/Source/cmMakefileTargetGenerator.cxx,v <-- cmMakefileTargetGenerator.cxx
new revision: 1.79; previous revision: 1.78
/cvsroot/CMake/CMake/Source/cmDepends.cxx,v <-- cmDepends.cxx
new revision: 1.17; previous revision: 1.16
/cvsroot/CMake/CMake/Source/cmDepends.h,v <-- cmDepends.h
new revision: 1.14; previous revision: 1.13
/cvsroot/CMake/CMake/Source/cmDependsFortran.cxx,v <-- cmDependsFortran.cxx
new revision: 1.33; previous revision: 1.32
/cvsroot/CMake/CMake/Source/cmDependsFortran.h,v <-- cmDependsFortran.h
new revision: 1.10; previous revision: 1.9

Added cleaning of modules and timestamps:

/cvsroot/CMake/CMake/Source/cmDependsFortran.cxx,v <-- cmDependsFortran.cxx
new revision: 1.34; previous revision: 1.33
/cvsroot/CMake/CMake/Source/cmLocalUnixMakefileGenerator3.cxx,v <-- cmLocalUnixMakefileGenerator3.cxx
new revision: 1.228; previous revision: 1.227

Added tests based on Maik's test cases:

/cvsroot/CMake/CMake/Tests/Fortran/CMakeLists.txt,v <-- CMakeLists.txt
new revision: 1.10; previous revision: 1.9
/cvsroot/CMake/CMake/Tests/Fortran/Executable/CMakeLists.txt,v <-- CMakeLists.txt
initial revision: 1.1
/cvsroot/CMake/CMake/Tests/Fortran/Executable/main.f90,v <-- main.f90
initial revision: 1.1
/cvsroot/CMake/CMake/Tests/Fortran/External/CMakeLists.txt,v <-- CMakeLists.txt
initial revision: 1.1
/cvsroot/CMake/CMake/Tests/Fortran/External/a.f90,v <-- a.f90
initial revision: 1.1
(0010033)
Brad King   
2007-12-30 16:17   
I've now implemented support for module output directory specification and mapping of the include directory path to module directory path on Sun. There is a new "Fortran_MODULE_DIRECTORY" target property that is initialized by the CMAKE_Fortran_MODULE_DIRECTORY variable. It will be used only if the compiler is known to support module output directories. Flags for GCC, Sun, and Intel are currently known.

/cvsroot/CMake/CMake/Modules/Platform/Linux-GNU-Fortran.cmake,v <-- Linux-GNU-Fortran.cmake
initial revision: 1.1
/cvsroot/CMake/CMake/Modules/Platform/Linux-SunPro-Fortran.cmake,v <-- Linux-SunPro-Fortran.cmake
new revision: 1.3; previous revision: 1.2
/cvsroot/CMake/CMake/Modules/Platform/Linux-ifort.cmake,v <-- Linux-ifort.cmake
new revision: 1.4; previous revision: 1.3
/cvsroot/CMake/CMake/Source/cmDependsFortran.cxx,v <-- cmDependsFortran.cxx
new revision: 1.37; previous revision: 1.36
/cvsroot/CMake/CMake/Source/cmDependsFortran.h,v <-- cmDependsFortran.h
new revision: 1.11; previous revision: 1.10
/cvsroot/CMake/CMake/Source/cmDocumentVariables.cxx,v <-- cmDocumentVariables.cxx
new revision: 1.8; previous revision: 1.7
/cvsroot/CMake/CMake/Source/cmMakefileTargetGenerator.cxx,v <-- cmMakefileTargetGenerator.cxx
new revision: 1.81; previous revision: 1.80
/cvsroot/CMake/CMake/Source/cmMakefileTargetGenerator.h,v <-- cmMakefileTargetGenerator.h
new revision: 1.19; previous revision: 1.18
/cvsroot/CMake/CMake/Source/cmTarget.cxx,v <-- cmTarget.cxx
new revision: 1.170; previous revision: 1.169
/cvsroot/CMake/CMake/Tests/Fortran/CMakeLists.txt,v <-- CMakeLists.txt
new revision: 1.12; previous revision: 1.11
/cvsroot/CMake/CMake/Tests/Fortran/Executable/CMakeLists.txt,v <-- CMakeLists.txt
new revision: 1.2; previous revision: 1.1
/cvsroot/CMake/CMake/Tests/Fortran/Library/CMakeLists.txt,v <-- CMakeLists.txt
new revision: 1.2; previous revision: 1.1
(0010035)
Brad King   
2007-12-31 11:27   
I've committed the module timestamp optimization feature. The changes are based on a patch from Maik:

/cvsroot/CMake/CMake/Source/cmDependsFortran.cxx,v <-- cmDependsFortran.cxx
new revision: 1.38; previous revision: 1.37
/cvsroot/CMake/CMake/Source/cmDependsFortran.h,v <-- cmDependsFortran.h
new revision: 1.12; previous revision: 1.11

This should reduce rebuilds due to dependencies on modules that have not really changed.
(0010036)
Maik Beckmann   
2007-12-31 13:12   
please ignore full_fortran_support_rev0.patch.

The current CVS-HEAD supersets this patch by far.

 -- Maik
(0010159)
Brad King   
2008-01-15 21:09   
I've updated http://www.cmake.org/Wiki/CMake_Fortran_Issues [^] with a note that first-class Fortran support will be available in CMake 2.6. This but entry may now be closed.