Home > Archive > Fortran > December 2005 > Re: compilation cascades (yet again)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: compilation cascades (yet again)
|
|
| Jan Vorbrüggen 2005-12-08, 7:59 am |
| From your post, the premise seems to be that you want to avoid unnecessary
compilation, still use modules if at all possible, and be portable across
compilers (so no compiler-specific hacks).
It seems to me that this can only be done at the moment if you have a tool
- which might be what's between your prgorammers's ears 8-) - that decides
whether the interface has been modified in the edit currently being checked
in, or not. If yes, remove the previously compiled module file; if no, leave
it in place. Then, intentionally run the compilation process such that the
generated mod file is ignored by the succeeding compile steps; only if one
should be missing, make is configured such that it moves the new one into
the place of the "reference" version that is used by those succeeding compile
steps.
This relies on an "intelligent" process to note when an interface change did
happen, and only then triggering the compilation cascase. Whether that's work-
able or not is for you to say. You could even use f90aib as part of that tool.
Jan
| |
| Bil Kleb 2005-12-08, 7:15 pm |
| Jan Vorbrüggen wrote:
> From your post, the premise seems to be that you want to avoid unnecessary
> compilation, still use modules if at all possible, and be portable across
> compilers (so no compiler-specific hacks).
Yes, well summarized.
[module differences recipe elided]
> This relies on an "intelligent" process to note when an interface change
> did happen, and only then triggering the compilation cascase.
This is the solution given by Stern and Grimwood in
http://www.theochem.uwa.edu.au/fort...compile/article
http://www.theochem.uwa.edu.au/fortran/recompile/
The trouble is that each compiler vendor cooks up a
different .mod file behavior which makes a general,
portable solution elusive.
Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov
| |
| James Giles 2005-12-08, 7:15 pm |
| Jan Vorbrüggen wrote:
....
> This relies on an "intelligent" process to note when an interface
> change did happen, and only then triggering the compilation cascase.
> Whether that's work- able or not is for you to say. You could even
> use f90aib as part of that tool.
This assumes that an interface change is the only reason that
you might need to recompile. Since modules inherently involve
dependent compilation, there's nothing to prevent an implementation
from always doing aggressive interprocedural optimizations (up to,
and maybe including inlining) on *all* modules procedures. That
may not happen to be true in most implementations, or the ones
you happen to use, but I would consider it a selling point if module
procedures were optimized that way.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Bil Kleb 2005-12-08, 7:15 pm |
| James Giles wrote:
> Jan Vorbrüggen wrote:
>
> This assumes that an interface change is the only reason that
> you might need to recompile. [..optimization being another..]
Excellent point.
For our need (software-developer productivity on a large
application using agile software development practices),
optimization is not an issue until we do a "production"
build, which is /very/ rare compared to hour-to-hour
changes (and recompilations) due to several developers
working concurrently.
Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov
| |
| Jan Vorbrüggen 2005-12-09, 4:15 am |
| > The trouble is that each compiler vendor cooks up a
> different .mod file behavior which makes a general,
> portable solution elusive.
Well, the "general, portable solution" uses, as I said,
the wetware to be found (I do hope) between the ears of
your developers - that solution should be totally inde-
pendant of any details of .mod file behaviour.
Whether said wetware considers that an acceptable solu-
tion is, of course, another matter.
Jan
|
|
|
|
|