Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Program to create a Makefile

pacobraxe
Beginner
447 Views
Hi,

I just create a fortran program that constructs a makefile suitable to compile and link a Fortran project. The idea is that it is hard to type in the Makefile all the dependencies between modules when you have a lot of files.
This program opens every fortran file stored in a set of folders (given by the user), searches the main program and all the dependencies to construct the Makefile.

I would like to ask you if you think whether this program can be useful for someone. How do you create your Makefiles?

Best regards,
Paco Braxe
0 Kudos
11 Replies
david_car
New Contributor I
447 Views
Hi Paco, I have a Python tool that does just that. It will be a separate tool as part of the next release of my opensource project. Check the link in my signature below.
0 Kudos
mecej4
Honored Contributor III
447 Views
There are at least three tools that I am aware of that analyze dependencies and assist with a command line build of a Fortran program that spans many source files: Automake from Polyhedron, fmkmf and mkmf (Google for them). As far as I know, none of the three is smart enough to help in suppressing the unnecessary recompiles of dependents that are caused when a source file is changed without changing the interfaces of the routines in the file.

In other words, if file F1.f90 contains a declaration of module xx, and file F2.f90 USEs module xx, and I make changes to the implementation parts of F1.f90, e.g., just adding a WRITE statement, it would be nice not to have to recompile F2.f90 after recompiling F1.f90
0 Kudos
jimdempseyatthecove
Honored Contributor III
447 Views
>>In other words, if file F1.f90 contains a declaration of module xx, and file F2.f90 USEs module xx, and I make changes to the implementation parts of F1.f90, e.g., just adding a WRITE statement, it would be nice not to have to recompile F2.f90 after recompiling F1.f90

Seperate your modules into two parts:

Data with interfaces
and
Code only (or code with private data)

The "Data with interfaces" won't change with the code change containing the write. Therefor the F2.F90 will not recompile, but it will re-link.

I typically use

MOD_foo.f90 (Data with interfaces)
MOD_foo_code.f90 (Code only )

The code only gets lib'ed into a library.

Jim Dempsey
0 Kudos
pacobraxe
Beginner
447 Views
In the book M. Metcalf et al. "Fortran 95/2003 Explained" gives a solution in Appendix D. He proposes a recursive make invocation to avoid the cascade of recompilations.

Paco Braxe
0 Kudos
jimdempseyatthecove
Honored Contributor III
447 Views
In IFVfortran a source that produces a module produces a .mod file and optional .obj file (.o file for Linux users). Where the .obj/.o file contains the static data and/or code when source has data and/or code. IVF timestamps the .mod and .obj files to assure from same build.

The user griped about having to recompile source files containing USE SomeModule when the change was non-functional such as adding a WRITE statement for debugging purposes (assumption on my part). Recursive make invocation does nothing to avoid the cascade of recompilation.

What does eliminate (greatly reduce) the cascade of recompilation is to structure the source file such that the source for the module contains only the interfaces and data that does not change. If you seperate the code that were placed in the CONTAINS section, into a seperate source file than USE'd the new module file (with just the interfaces and data) then the new fileproduces a stand-alone object file that can either be linked directly or placed into a library and linked by way of the library. With this structure, adding the write statement does NOT alter the .mod file nor the accompanying .obj/.o file. But it will alter the .obj/.o file that stands seperate from the module .mod and .obj/.o files. IOW other sources having USE will see no dependency change when adding/removing diagnosticWRITE statements.

The remaining circumstances you will notice the recompilation is after making a change to the data and/or interfaces within the split-form module.

Jim Dempsey
0 Kudos
mecej4
Honored Contributor III
447 Views
I agree with what Jim said. In fact, Appendix D of Fortran 95/2003 Explained makes similar recommendations, but in the context of how to use the recommendations with makefiles.

My comments were about the tools that generate makefiles, which was what the OP asked about. I remarked that the tools did not implement the recommendations of Appendix D automatically.

The issue became a bother to me only when hunting bugs in some large third party packages in which I wanted to detect and fix bugs, without changing the source code beyond what was the least change needed to remove the bugs. Most of us are touchy about our favorite coding styles, and in these instances I needed to keep that in mind.
0 Kudos
jimdempseyatthecove
Honored Contributor III
447 Views
>>The issue became a bother to me only when hunting bugs in some large third party packages in which I wanted to detect and fix bugs, without changing the source code beyond what was the least change needed to remove the bugs. Most of us are touchy about our favorite coding styles, and in these instances I needed to keep that in mind.

Perhaps the Intel compiler writers can consider the reasonableness of being able to make such a modification without having the requirement to recompile all files containing the USE module.

One method to do this isfor the compiler to produce module_foo.mod.temp and module_foo.obj (module_foo.o) then perform a diff between module_foo.mod.temp and module_foo.mod.Only if substantively different then delete old and replace with new. Theobject file though isupdated but is not required to have the same time stamp as the .mod file.Any and library dependent on the .obj gets re-lib'd, and any executable dependent on the .obj gets re-linked. However, all source files dependent on module have no requirement for re-compilation.

This is not an unusual circumstance.

Jim Dempsey
0 Kudos
mecej4
Honored Contributor III
447 Views
Jim, similar ideas occurred to me.

I, however, had doubts as to whether these changes should be made entirely in the compiler, in the makefile, or if Make itself would need to be given additional cababilities that it does not yet have, or some combination of all three. I cannot say that I know make so well as to answer these doubts.

If the compiler is to be changed, perhaps a new switch is needed which, by default, is off, so that users for whom this is not an issue continue to have their expectations met. Some compilers already have switches to suppress the generation of module files, but that is not enough, as your second paragraph shows.
0 Kudos
Steven_L_Intel1
Employee
447 Views
Today, there is a -syntax-only switch that will disable the creation of module files and objects. In the next major release, there will be a "-gen-dep" switch that will output dependency information suitable for makefiles.
0 Kudos
jimdempseyatthecove
Honored Contributor III
447 Views
Today, there is a -syntax-only switch that will disable the creation of module files and objects. In the next major release, there will be a "-gen-dep" switch that will output dependency information suitable for makefiles.


Will -gen-dep generate dependency information to seperate the .mod file has substantively changed (interface change or data change) and/or object file associated with .modchanged?

Jim

0 Kudos
Steven_L_Intel1
Employee
447 Views
All it does is output the dependency info on a file basis, with the syntax suitable for a makefile rule. How you determine that a module has "substantively changed" is outside the scope.
0 Kudos
Reply