f90 modules compilation
Marc Tajchman
Hi,
I need some advice on module compiling in fortran 90.
Any comments will be greatly appreciated.
Here is a code example in two separate files :
File A.f90 :
module A
public :: SubA
contains
subroutine SubA(x, y)
integer :: x, y
x = 5
y = 7
end subroutine SubA
end module A
File B.f90 :
module B
use A
public :: SubB
contains
subroutine SubB(z)
real z
integer i,j
call SubA(i,j)
z = 1.0 + i
...
end subroutine SubB
end module B
Module B in file B.f90 uses module A in file A.f90.
It seems logical to recompile both files after modifying public
information in file A.f90 (e.g. argument sequence in subroutine SubA).
But what if I replace line 'x = 5' by e.g. 'x = 6' in file A.f90 ?
How telling a make program not to perform unnecessary recompilation ?
I have a lot of modules in my code with multiple dependencies
(module A depends on module B which depends on module C ...).
So a small change in the private part of a single module may induce
several (and lenghty) recompilations.
I presently use Microsoft PowerStation on a PC and SunSoft Fortran 90
on a Sun workstation.
Thank you in advance for your comments,
_______________________________________________________________________
Marc Tajchman
e-mail: Marc.T...@cmla.ens-cachan.fr
Centre de Mathematiques et Leurs Applications,
Ecole normale superieure de Cachan,
France
Jim Giles
In article <33858D...@cmla.ens-cachan.fr>, Marc Tajchman
<Marc.T...@cmla.ens-cachan.fr> writes:
> It seems logical to recompile both files after modifying public
> information in file A.f90 (e.g. argument sequence in subroutine SubA).
>
> But what if I replace line 'x = 5' by e.g. 'x = 6' in file A.f90 ?
> How telling a make program not to perform unnecessary recompilation ?
Unfortunately, according to the rules of the standard, the
recompilation of B after such an internal change to A is
still required. We had a considerable debate about this
a few months ago (which I lost). It seems that most people
think it's desirable for a non-public change in a module to
still require recompilation of all uses of that module.
J. Giles
Ricercar Software
William Clodius
Marc Tajchman wrote:
> <snip>
> It seems logical to recompile both files after modifying public
> information in file A.f90 (e.g. argument sequence in subroutine SubA).
>
> But what if I replace line 'x = 5' by e.g. 'x = 6' in file A.f90 ?
> How telling a make program not to perform unnecessary recompilation ?
>
> (module A depends on module B which depends on module C ...).
> So a small change in the private part of a single module may induce
> several (and lenghty) recompilations.
Make is too primitive a tool to avoid such problems by itself. In order
to avoid such recompilations the compiler (or some other part of the
development environment) would have to maintain a database of program
units and their public interfaces, and cross check after compilation to
ensure that the interfaces haven't changed. If vendors provided
sufficiently smart linkers the object code could itself serve as the
"database", but unfortunately linkers are driven first by the
requirements of the OS, second by the requirements of the languages the
OS is primarilly written in (i.e., C and C++), third by the requirements
of the other major languages, i.e., Basic, Fortran, Ada, Pascal, and
Lisp, and are only slightly influenced by the convenience of the users.
Those language systems that provide such capabilities, e.g., some single
vendor languages or most (all?) Ada vendors, typically do so by
providing that information in a separate form.
IF you work primarilly on one system I would enclurage you to consider
this a high priority in your conversations with the vendors.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: wclo...@lanl.gov
William Clodius
Jim Giles wrote:
> <snip>
> recompilation of B after such an internal change to A is
> still required. We had a considerable debate about this
> a few months ago (which I lost). It seems that most people
> think it's desirable for a non-public change in a module to
> still require recompilation of all uses of that module.
Not quite an accurate statement of the discussion. Most of the
discussion focussed on what the standard did and should say about that
issue. Whether and how it should be addressed by the standard is a
different issue from whether a capability is desirable in general.
The concensus (or perhaps majority opinion would be a better term) was
that it was not useful for the Fortran standard to specify that a
non-public change in a module must not require recompilation of all uses
of that module. There was some discussion as to whether the wording in
the standard made recompilation a requirement. I (and I believe Richard
Maine) believed that the standard allowed compilers to implement
minimization of recompilation due to its processor defined clauses in
the appropriate places in the standard. However, it is certainly true
that the standard does not provide a portable way of avoiding such
recompilations.
As to those who voiced an opinion on the desirability of avoiding
recompilation, there were a few who did not want that capability if it
prevented them from using make on such systems (unless it was
implemented in a universally portable manner, which is probably beyond
the Fortran standards purview), a few that wanted it to be part of the
standard, and some that considered that capability to be a quality of
implementation issue. Of course unless the standard requires it, or the
public gives such capabilities a high priority (they have not done so at
this time), we are left in the situation where insignificant changes
cause unnecessary recompilations.
Viggo Norum
Marc Tajchman <Marc.T...@cmla.ens-cachan.fr> writes:
>
> I have a lot of modules in my code with multiple dependencies
> (module A depends on module B which depends on module C ...).
> So a small change in the private part of a single module may induce
> several (and lenghty) recompilations.
>
Free advice: Use two makefiles, one with dependencies and one without.
Let the Makefile contain just "include Nodep" and the dependencies
(assuming that you called the makefile without dependencies "Nodep").
Then you can do something like "make -f Nodep" when you are sure the
small change in the code will not alter the interface.
Note that this approach may be dangerous, but
it works on some (most? all?) systems.
An alternative is to put the dependencies inside "ifndef NODEP
... endif" and set NODEP when you don't want dependency checking.
--
Viggo L. Norum