[asdf-devel] compile-with-nicknames (a possible compromise?)
Juan Jose Garcia-Ripoll
juanjose.garciaripoll at googlemail.com
Mon Oct 17 08:58:36 UTC 2011
2011/10/17 Gábor Balázs <gabalz at gmail.com>
>
> Hm, I like the idea of having multiple classes for cl-source-file objects.
> But I wouldn't do it through CLOS.
I tend to agree on this, for CLOS is not declarative. It would become very
hard to automatically deciphering defsystem files, and what they do.
I also believe that the wrap-around functionality does not have to be that
general. In particular this is specifically required only for _compiling_,
not for loading. I would not want an :around semantics to exist at all for
loading, because that would completely eliminate any possible and future
goal of making ASDF ship pre-compiled libraries.
Out of the tasks listed here:
locally renaming packages
binding *readtables* and other syntax-controlling variables
handling warnings and other conditions
proclaiming optimization settings
saving code coverage information
maintaining meta-data about compilation timings
resetting gensym counters, PRNG seeds, etc., for determinism
cheating the source-location and/or timestamping systems
checking that some cleanup function was properly called
etc.
I see nothing that could not exist in :eval-when forms. The problem is thus
not that these operations may live in the compiled files, but the fact that
we need them to be executed every time the files in the system are compiled.
In a sense, it is a _reversed_ dependency. Normally we have that file2
depends on file1 and thus file2 is loaded _after_ file1 is loaded. Couldn't
we just add another component to defsystem which is loaded when _any_ file
is to be changed? It would be like a prerequisite module or file.
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20111017/40a096c8/attachment.html>
More information about the asdf-devel
mailing list