View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005809CMakeCMakepublic2007-10-01 05:252012-08-15 08:22
ReporterMaik Beckmann 
Assigned ToBrad King 
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.
Additional InformationThings that should work are...

  1. comments in fixed-format can contain the "use" keyword.
     (see: [^])
      PROGRAM hello
C USE foo

      WRITE(*,*) 'Hello, Fortran world.'
project(test Fortran)

add_executable(main main.f)

    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.
Attached Filespatch file icon makedepf90-2.8.8_port_cm-2.4.7.patch [^] (14,921 bytes) 2007-10-01 05:25 [Show Content]
gz file icon lib_dep_example.tar.gz [^] (527 bytes) 2007-10-01 06:37
gz file icon missing_mod_dep.tar.gz [^] (318 bytes) 2007-10-01 14:46
patch file icon test_use_in_comment.patch [^] (1,337 bytes) 2007-10-06 15:23 [Show Content]
gz file icon example_simpleProgram.tar.gz [^] (541 bytes) 2007-10-08 08:24
gz file icon examples_using_Makefiles.tar.gz [^] (4,189 bytes) 2007-10-08 10:41
patch file icon in_interface.patch [^] (669 bytes) 2007-10-09 13:49 [Show Content]
? file icon in_interface.patch2 [^] (643 bytes) 2007-10-10 02:04
patch file icon Tests_Fortran.patch [^] (2,268 bytes) 2007-10-10 07:14 [Show Content]
patch file icon conservative_full_fortran_support_rev0.patch [^] (44,113 bytes) 2007-12-22 18:55 [Show Content]
patch file icon full_fortran_support_rev0.patch [^] (43,671 bytes) 2007-12-23 13:56 [Show Content]
gz file icon testcases_rev0.tar.gz [^] (2,365 bytes) 2007-12-23 13:59

related to 0003109closedBrad King Fortran dependancy checker does not ignore comments 
related to 0003195closedBrad King depend.make has incorrect f90 dependencies for USE 
related to 0003984closedBrad King A fortran 95 module dependency issue 
related to 0002361closedBrad King FORTRAN 9x module dependencies parsing 
related to 0003144closedBrad King cmake fails when fortran modules are saved in an otehr directory that the default one. 
related to 0013471closedBrad King CMake does not understand Fortran interface "module procedure" syntax 

Maik Beckmann (reporter)
2007-10-01 06:19

makedepf90-2.8.8_port_cm-2.4.7.patch works on current HEAD too.

Maik Beckmann (reporter)
2007-10-01 06:36

Things that should work...

2. build an executable which depends on a Fortran 95 library
   (see: [^])

    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.

Wim Van Hoydonck (reporter)
2007-10-01 11:46 [^] (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")?
Maik Beckmann (reporter)
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".

irwin (reporter)
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.
Maik Beckmann (reporter)
2007-10-02 02:56
edited on: 2007-10-02 02:59

Thanks to Alan for starting this wiki page:
    - [^]

I propose to use the wiki to collect and comment the topics, like
    1. comments in fixed-format can contain the "use" keyword.
    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.


Brad King (manager)
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/,v <--
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.
Brad King (manager)
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.
Brad King (manager)
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.
Brad King (manager)
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.
Brad King (manager)
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).
Brad King (manager)
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
irwin (reporter)
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.
Maik Beckmann (reporter)
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)

PS: Test for the "use" issue will be provided

Brad King (manager)
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!
Maik Beckmann (reporter)
2007-10-08 10:52
edited on: 2007-10-08 11:46


I put some content to [^] 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,

irwin (reporter)
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 [^] without intruding on technical issues.

Brad, I hope you will take a look at the technical issues.
Maik Beckmann (reporter)
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 [^]

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


Maik Beckmann (reporter)
2007-10-10 07:19

Tests_Fortran.patch adds Tests for
   - use keyword in comment
   - module keyword in interface


PS: Is it able to delete or mark uploaded files as obsolete?
Brad King (manager)
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
Brad King (manager)
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
Brad King (manager)
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.
Brad King (manager)
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.
Maik Beckmann (reporter)
2007-12-22 19:04


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
Maik Beckmann (reporter)
2007-12-23 13:56

Please _ignore_ conservative_full_fortran_support_rev0.patch

 -- Maik
Maik Beckmann (reporter)
2007-12-23 13:59


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
Maik Beckmann (reporter)
2007-12-23 14:12


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
Brad King (manager)
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
Brad King (manager)
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
Brad King (manager)
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.
Maik Beckmann (reporter)
2007-12-31 13:12

please ignore full_fortran_support_rev0.patch.

The current CVS-HEAD supersets this patch by far.

 -- Maik
Brad King (manager)
2008-01-15 21:09

I've updated [^] with a note that first-class Fortran support will be available in CMake 2.6. This but entry may now be closed.

 Issue History
Date Modified Username Field Change
2007-10-01 05:25 Maik Beckmann New Issue
2007-10-01 05:25 Maik Beckmann File Added: makedepf90-2.8.8_port_cm-2.4.7.patch
2007-10-01 06:19 Maik Beckmann Note Added: 0009341
2007-10-01 06:36 Maik Beckmann Note Added: 0009342
2007-10-01 06:37 Maik Beckmann File Added: lib_dep_example.tar.gz
2007-10-01 11:46 Wim Van Hoydonck Note Added: 0009346
2007-10-01 14:45 Maik Beckmann Note Added: 0009351
2007-10-01 14:46 Maik Beckmann File Added: missing_mod_dep.tar.gz
2007-10-01 17:38 irwin Note Added: 0009352
2007-10-02 02:56 Maik Beckmann Note Added: 0009360
2007-10-02 02:59 Maik Beckmann Note Edited: 0009360
2007-10-03 14:59 Bill Hoffman Assigned To => Brad King
2007-10-03 14:59 Bill Hoffman Status new => assigned
2007-10-03 15:42 Brad King Note Added: 0009372
2007-10-03 15:44 Brad King Note Added: 0009373
2007-10-03 15:46 Brad King Relationship added related to 0003109
2007-10-03 15:48 Brad King Relationship added related to 0003195
2007-10-03 15:48 Brad King Relationship added related to 0003984
2007-10-03 15:49 Brad King Relationship added related to 0002361
2007-10-03 15:53 Brad King Note Added: 0009374
2007-10-03 16:26 Brad King Note Added: 0009378
2007-10-03 16:28 Brad King Relationship added related to 0003144
2007-10-03 16:30 Brad King Note Added: 0009379
2007-10-03 17:04 Brad King Note Added: 0009380
2007-10-03 17:08 irwin Note Added: 0009381
2007-10-04 01:16 Maik Beckmann Note Added: 0009383
2007-10-04 05:40 Maik Beckmann Note Edited: 0009383
2007-10-04 09:43 Brad King Note Added: 0009384
2007-10-06 15:23 Maik Beckmann File Added: test_use_in_comment.patch
2007-10-06 15:25 Maik Beckmann Note Added: 0009395
2007-10-06 16:44 Maik Beckmann Note Edited: 0009395
2007-10-08 08:24 Maik Beckmann File Added: example_simpleProgram.tar.gz
2007-10-08 10:41 Maik Beckmann File Added: examples_using_Makefiles.tar.gz
2007-10-08 10:52 Maik Beckmann Note Added: 0009401
2007-10-08 11:46 Maik Beckmann Note Edited: 0009401
2007-10-08 12:19 irwin Note Added: 0009402
2007-10-09 13:48 Maik Beckmann Note Added: 0009407
2007-10-09 13:49 Maik Beckmann File Added: in_interface.patch
2007-10-10 02:03 Maik Beckmann Note Edited: 0009407
2007-10-10 02:04 Maik Beckmann File Added: in_interface.patch2
2007-10-10 02:04 Maik Beckmann Note Edited: 0009407
2007-10-10 07:14 Maik Beckmann File Added: Tests_Fortran.patch
2007-10-10 07:14 Maik Beckmann Note Deleted: 0009395
2007-10-10 07:19 Maik Beckmann Note Added: 0009408
2007-10-10 09:09 Brad King Note Added: 0009410
2007-10-10 09:10 Brad King Note Added: 0009411
2007-10-10 09:18 Brad King Note Added: 0009412
2007-10-12 09:53 Brad King Note Added: 0009426
2007-12-22 18:55 Maik Beckmann File Added: conservative_full_fortran_support_rev0.patch
2007-12-22 19:04 Maik Beckmann Note Added: 0010015
2007-12-23 13:56 Maik Beckmann Note Added: 0010016
2007-12-23 13:56 Maik Beckmann File Added: full_fortran_support_rev0.patch
2007-12-23 13:59 Maik Beckmann Note Added: 0010017
2007-12-23 13:59 Maik Beckmann File Added: testcases_rev0.tar.gz
2007-12-23 14:12 Maik Beckmann Note Added: 0010018
2007-12-28 11:55 Brad King Note Added: 0010029
2007-12-30 16:17 Brad King Note Added: 0010033
2007-12-31 11:27 Brad King Note Added: 0010035
2007-12-31 13:12 Maik Beckmann Note Added: 0010036
2008-01-15 21:09 Brad King Status assigned => closed
2008-01-15 21:09 Brad King Note Added: 0010159
2008-01-15 21:09 Brad King Resolution open => fixed
2012-08-15 08:22 Brad King Relationship added related to 0013471

Copyright © 2000 - 2018 MantisBT Team