[asdf-devel] Minor simplification

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Sun Feb 6 21:58:46 UTC 2011


On Sun, Feb 6, 2011 at 10:23 PM, Faré <fahree at gmail.com> wrote:

> Where is the behavior to be coded? Surely it must be coded somewhere.
> Is it unreasonable to upgrade ASDF when new code is required, and to change
> few boolean controls to select which branch of the code applies?
>

Please, understand, I do not want to commit to a particular behavior right
now. I do not know yet how I am going to code the bytecodes compiler, or if
I will allow multiple variants or whether I will have something which is
build-fasl-like in a third phase of development.

I want freedom on developing my ECL side of the code while preserving
compatibility and minimal intrusiveness. I do not want to have to come here
and ask for every single change every time I make different design choice,
or even worse, keeping track of versions. Pluggin in into ASDF should be
done from my own extensions (asdf-ecl and new compiler backends) and not by
hardcoding behavior into ASDF where it does not belong.

I think what I am suggesting is pretty reasonable.

1* COMPILE-FILE* right now has a very well defined purpose, (compile a
single lisp file with error handlers) which I believe should not be touched
if it is going to be exported as a tool. Move back from method to function.
2* Right now the only ECL-dependent behavior is in PERFORM when applied on
COMPILE-OP and on OUTPUT-FILES acting on the same operator. Get these
changes away by default.
3* The ECL-specific part only makes sense and only is needed when combined
when asdf-ecl.lisp, which itself only makes sense when used with the current
C compiler. This can be moved to asdf-ecl.
4* Allow a simple way to plug into the compile-op actions. An :around method
is too complicated because there may be more layers and using MOP is both
nonportable, non-future proof, and a mess -- what methods to add, what to
remove? bootstrapping problems, versioning...

Everything is atached to this email. Just one single hook (a special
variable), removed all ECL-specific logic from asdf.lisp, and back into
asdf-ecl.lisp, where it belongs, non-intrusively.

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/20110206/cca5a661/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asdf-ecl-patches.diff
Type: application/octet-stream
Size: 5410 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20110206/cca5a661/attachment.obj>


More information about the asdf-devel mailing list