[asdf-devel] Semantic of ASDF Dependencies
Faré
fahree at gmail.com
Tue Jul 6 14:43:08 UTC 2010
On 6 July 2010 05:08, Benjamin Benninghofen
<Benjamin.Benninghofen at eads.com> wrote:
> Assume we have files "packages" "macros" "classes" "methods" "functions"
> and we want the following dependencies:
>
> 1. In order to compile or load any of the other files the file
> "packages.fasl" must be loaded.
>
> 2. In order to compile or load "methods" the file "classes.fasl"
> must be loaded.
>
> 3. The file "macros" contains macros used in "methods" and "functions"
> and hence "macros.fasl" must be loaded before any of these 2 files
> is compiled or loaded. Furthermore when "macros" is changed also
> "methods" and "functions" have to be recompiled even if they are
> unchanged.
>
> 4. There shall be no more dependencies, i.e. when a file different from
> "macros" is changed, only this file shall be recompiled.
>
>
> With the Symbolics System Construction Tool (SCT) one would use
> (:USES-DEFINITIONS-FROM macros) for methods and functions
> and (:IN-ORDER-TO (:COMPILE :LOAD) (:LOAD packages ...)) for the
> other dependencies.
>[...]
> For example when "classes" is changed it will recompile "methods" too.
> Is there anything in ASDF that provides the functionality of the SCT
> :IN-ORDER-TO ?
>
Dear Benjamin,
I don't think this is currently possible in ASDF, and moreover,
I don't think it would be a good idea to add this feature.
Indeed, not recompiling when something change means you introduce
more non-deterministic state-dependence in compilation, and that
things will fail in subtle ways when the declarations from files
other that macros.lisp change - for instance, when you modify a class,
an inline definition, etc. In these cases, I suppose the SCT relied
on the user to force the recompilation, moving some of the dependency
state from the machine to the user's head. Except that this doesn't
scale to a half-a-million line program by tens of programmers.
I think this is bad practice. It would be more interesting if one could
automatically extract fine-grained dependency and change information,
and use that to drive recompilation. ASDF-DEPENDENCY-GROVEL tries to do
that, but it's making crazy approximations, requires some user help, and
only scales so well. Something based on actual code coverage could be
better, but we don't have it.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
... Any resemblance between the above views and those of my employer,
my terminal, or the view out my window are purely coincidental. Any
resemblance between the above and my own views is non-deterministic. The
question of the existence of views in the absence of anyone to hold them
is left as an exercise for the reader. The question of the existence of
the reader is left as an exercise for the second god coefficient. (A
discussion of non-orthogonal, non-integral polytheism is beyond the scope
of this article.)
More information about the asdf-devel
mailing list