GNU autotools can not only handle making (Compiling and linking), distributing, transplanting source code for different platforms, but can also track file dependencies hence reduce redundant compiling. this property is by default enabled for C/C ++ programming and one of the measures taken by automake to achieve this automatic tracking is implemented
How to initialize a bootstrap
Use 'make all' to create dependencies while compiling the source code. After this step, 'make' is able to work normally.
If there are auto generated header files, the compiler wocould complain about header file lost during the above Bootstrap step. it is therefore suggested by automake that these header files shoshould be added to the variable built_sources, which ensures that these files are generated before the real compiling procedure begins.
The generation of these headers files is usually explicitly based on user defined generation or compiling rules.
The above procedures are actually valid tive for C/C ++ because the inter-dependencies between different source files explicitly rely upon user written header files or explicitly User-Defined generation rules. for Fortran 90 programming, the concomitant *. MOD files play the role of header files in C/C ++. because they are automatically generated concomitantly with corresponding object files containing implementation of modules, there are no explicit User-Defined generation rules for these *. MOD files. hence, it is useless to put these *. MOD files into the variable built_sources. if no other measures are taken to deal with *. MOD files, Fortran compiler will not be able to proceed normally.
Although a FORTRAN file referencing a module written in another file, for example. f90, is dependent on. moD, we can actually write the dependency as follows without any problem just because *. MOD files are generated simultaneously *. O files, the dependency on *. MOD files is equivalent to dependency on corresponding *. O files:
main.o: a.o
Because automake knows how to compile *. f90 into *. O files, the whole dependency tree can be generated.
In my previous implementation, the dependency relationships for each *. f90 file is written in a respective file with the same base name appending by an extension *. Po and such a file is located in. DepsFolder in each directory. the reason to do this is to mimic the automake's support for C/C ++ dependency tracking. it seems that it really worked in previous tests. however, right now automake doesn' t include the contents of these *. po file into the final makefile. it is so strange!
Because there is no existing solution both simple and valid tive for detecting Fortran source file dependencies, a Perl scriptFdepcomp. plIs written by me to perform this task. The generated dependency relationships are written in a file namedMakedepsIn each directory. For the first attempt, These dependencies are generated like this:
main.o: $(top_builddir)/Defs.o $(top_builddir)/PhysConst.o $(top_builddir)/MathFunc.o $(top_builddir)/ReadFile.oMathFunc.o: $(top_builddir)/Defs.oPhysConst.o: $(top_builddir)/MathFunc.oReadFile.o: $(top_builddir)/MathFunc.o
However, compiler still reported error. Initially, I was unaware of the potential problem. After changing the above relationships into the following, the compiling process was normal again:
main.o: Defs.o PhysConst.o MathFunc.o ReadFile.oMathFunc.o: Defs.oPhysConst.o: MathFunc.oReadFile.o: MathFunc.o
The reason for this is: taking an arbitrary file as an example, the dependent file name$ (Top_builddir)/defs. oIs not equivalent to the target file nameDefs. oFrom the view of automake. It is obvious to imagine that the following are also valid format describing dependencies:
$(top_builddir)/main.o: $(top_builddir)/Defs.o$(top_builddir)/PhysConst.o$(top_builddir)/MathFunc.o$(top_builddir)/ReadFile.o$(top_builddir)/MathFunc.o: $(top_builddir)/Defs.o$(top_builddir)/PhysConst.o: $(top_builddir)/MathFunc.o$(top_builddir)/ReadFile.o: $(top_builddir)/MathFunc.o