Fortran - compilation cascades and new Fortran features

Author

compilation cascades and new Fortran features

Pierre Hugonnet

2005-09-29, 3:57 am

Hello,

I gave up with the so-called "compilation cascade" problem a few ago
years ago. The last not-too-bad solution I could read to solve that
problem was based on the comparison between the new and old module
files: if they are identical then there's no need to recompile the
files that USE the modules of the newly recompiled file:
http://tinyurl.com/btsqg
http://groups.google.com/group/comp...b876dd2581acd7e

Now, I am wondering if some the new features introduced in F2003 bring
new solutions for that problem ? Could you comment on that ?

Regards,

Pierre

Dan Nagle

2005-09-29, 7:57 am

Hello,

Pierre Hugonnet wrote:
> Hello,
>
> I gave up with the so-called "compilation cascade" problem a few ago
> years ago.

<snip>

> Now, I am wondering if some the new features introduced in F2003 bring
> new solutions for that problem ? Could you comment on that ?

The solution isn't formally in f03, but in the Enhanced Modules TR,
which has been formally published by ISO. I expect vendors will
implement it before getting absolutely everything in f03 working.

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

robert.corbett@sun.com

2005-09-29, 9:57 pm

> Now, I am wondering if some the new features introduced in
> F2003 bring new solutions for that problem ? Could you
> comment on that ?

No. Make is not capable of handling the usual implementation of
Fortran modules without either missing some necessary rebuilds
or doing some extra rebuilds. Make could be extended to deal
with Fortran modules, but I don't know of work being done along
those lines.

Bob Corbett

Richard Maine

2005-09-30, 3:57 am

In article <1128044164.165927.200640@g43g2000cwa.googlegroups.com>,
robert.corbett@sun.com wrote:

>
> No. Make is not capable of handling the usual implementation of
> Fortran modules without either missing some necessary rebuilds
> or doing some extra rebuilds. Make could be extended to deal
> with Fortran modules, but I don't know of work being done along
> those lines.

Please note that the question was specifically about the new features of
f2003. As noted in another reply, the modules TR to f2003 has features
that *DO* specifically address this problem. There are, as of yet, no
"usual" implementations of that. The question of when there might be any
is another matter.

I will note that several compiler vendors have specifically commented
that they see enough demand for the modules TR that they may well
implement it in f95 compilers before completing all the base f2003
features.

robert.corbett@sun.com

2005-09-30, 3:57 am

> Please note that the question was specifically about the new features of
> f2003. As noted in another reply, the modules TR to f2003 has features
> that *DO* specifically address this problem.

The modules TR allows users to write their code in a way that solves
part
of the problem. It allows users to split the implementation and
specification
parts of a module into separate files. Even if a user does that, if
he touches
the file containing the specification part, a compilation cascade can
still
result.

Bob Corbett

Richard Maine

2005-09-30, 3:57 am

In article <1128052703.267843.29020@f14g2000cwb.googlegroups.com>,
robert.corbett@sun.com wrote:

> The modules TR allows users to write their code in a way that solves
> part of the problem...
> Even if a user does that, if he touches the file containing the
> specification part, a compilation cascade can still result.

Or, to put it in more general terms. Using any language with any
features, in conjunction with make, if the user incorrectly touches a
file on which everything else depends, he can get a compilation cascade.
Or to put it even more generally, if a user messes up, he can get
screwed. While true, this is not particularly unique to Fortran modules.

The modules TR gives the user the capability to solve the problem. It
does not force the user to use that capability. Nor does it protect
against all possible screw ups.

I suppose another point to be made is that the protection is only
against spurious compilation cascades. If you actually change something
in the specification part, then the compilation cascade is no longer
spurious. Perhaps that's what you were saying. I'd note in that regard
that appropriate organization of modules can ameliorate such problems by
sufficiently separating those specifications which might regularly need
changing; make sure that they aren't grouped with other things that have
more pervasive dependencies.

Which is to say that, yes, you have to learn to use the tools
appropriately. Just waving a wand over the modules TR won't help.

robert.corbett@sun.com

2005-09-30, 3:57 am

It is not just a matter of doing something incorrect. A user
might, for example, want to update a comment in the file
containing the specification part of a module.

Also, some existing Fortran 95 compilers inline references
to small module procedures. People using such
implementations might not want to pay the performance
hit for moving those module procedures into separate
implementation files.

I agree that programmers can help themselves a lot by
assigning modules to files in an orgainized way. In
almost all cases, each module should be in a separate
source file. There should be no other code in the file.
The basename of the source file should be the same as
the basename of the generated .mod file.

Bob Corbett

Gordon Sande

2005-09-30, 8:01 am

On 2005-09-29 22:36:04 -0300, robert.corbett@sun.com said:

>
> No. Make is not capable of handling the usual implementation of
> Fortran modules without either missing some necessary rebuilds
> or doing some extra rebuilds. Make could be extended to deal
> with Fortran modules, but I don't know of work being done along
> those lines.
>
> Bob Corbett

The MacOs (not the MacOsX based on Unix) had a developer environment
that was command line based and looked much like Unix in many repsects
but also paid attention to the multiple windows etc. It was MPW for
Macintosh Programmers Workbench and was an interesting hybrid.

MacOs files have both data and resource forks so the MPW version of
make had to know how to keep track of two outputs and make sure
they got pasted together etc. The problem sould seem to be a kissing
cousin of the object/module problem of F90. There was a layer of
extra fuss that did not seem excessive for the problem being solved.
The MPW make would be an interesting lesson to look at to see how
a different group solved and similar problem. Unfortunately MPW is
fast receding into the dust of history as MacOs now lives as Classic
under MacOsX and will not be present under the soon to be MacTel MacOsX.

MacOsX uses a package notion so the issues do not arise for Xcode,
their new developer environment. A package is a directory that can
inform the system that it and its contents are to be treated as a
unit and displayed as it they were a file unless the contents are
explicitly requested. They have now even taught the command line in
Unix to follow the same conventions as the GUI on this issue.

Richard E Maine

2005-09-30, 6:59 pm

In article <1128063375.255265.308390@g44g2000cwa.googlegroups.com>,
robert.corbett@sun.com wrote:

> It is not just a matter of doing something incorrect. A user
> might, for example, want to update a comment in the file
> containing the specification part of a module.

And this is nothing unique to modules or even to Fortran. That is an
inherent "feature" of make in that it is based solely on file
modification times. In pretty much any kind of file that might be
involved in any language, you might have the same phenomenon of wanting
to update a comment and thus causing spurious recompilations. I could
spend a long time railing about the deficiencies of make, but that would
be both pointless and off-topic.

The design of modules in f90/f2003 is particularly prone to causing
spurious compilation cascades with make. That certainly sounded like
what the OP was asking about. I stick with my original comment that the
modules TR specifically addresses the question that the OP asked about.
It does not change the fundamental nature of make. It does, however,
specifically address the issue that modules caused worse problems with
make cascades than did other mechanisms.

This does not mean that you can't get compilation cascades. That is
fundamental to make. It doesn't mean that you can't get spurious ones.
That is just about as fundamental to make. It doesn't solve the inherent
issues (which you raised) of wanting compilation to be both separate and
inlined. (I have heard of schemes to address that by having the compiler
actually making both versions, but that seems to have nothing in
particular to do with either make or modules, as it comes up in
non-module cases without using make). The TR also doesn't solve world
hunger, in case anyone wondered. But I didn't see all those questions in
the OP's posting.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

robert.corbett@sun.com

2005-09-30, 9:57 pm

> And this is nothing unique to modules or even to Fortran. That is an
> inherent "feature" of make in that it is based solely on file
> modification times.

Right. As I said in my first posting in this thread
[color=darkred]

Bob Corbett

Sponsored Links