[asdf-devel] New ASDF maintainer sought

[Juan Jose Garcia-Ripoll]

There is a rationale for the splitting of asdf.lisp.

* Sorry, but the excuse of searching for code in a file is lame :-) Would
that also apply to any thousand lines code library?

* The bootstrapping code can be different for a shipped asdf (one that comes
with the implementation) and for the asdf that is loaded by users. This can
be activated by an implementation by choosing whether to use defpackage.lisp
or something else. Doing this with the monolithic asfd.lisp is a hell.

* The limitation of having a single asdf.lisp file is not insurmountable. It
is currently due to a problem in ASDF definitions, which force a
compile-load-compile-load-- sequence for the files, not allowing a
compile-compile-compile... + load-load-load... The current model has the
problem that as soon as new classes are loaded, the ASDF that is driving the
build breaks down. I understand that this can be solved writing a better
asdf.asd that includes serial :in-order-to (:compile-op ...) dependencies.
Another less pleasant alternative would be to build ASDF in a separate
bootstrapping package and then transferring the old database of modules to
the new version (i.e. changing the current bootstrapping code).

* In the meantime asdf.lisp may be automatically created and distributed
together with the rest. This imposes no maintenance burden and it can be
actually used to ensure that asdf.lisp is only created with new releases,
leaving the other files and directories for daring users / maintainers.

* I have been able to identify structure in the code and splitting it into
files which are actually independent and which are connected by a yet flaky
API (methods principally). This has been the criterion for splitting. The
current asdf.lisp is a mess where it is extremely hard to identify all the
methods defined for a class.

* In the split form methods and classes are logically grouped. It makes it
easy to restrict oneself to good coding practices, such as enforcing an API
for the different components to communicate among each other, and looking
for strategies to optimize and trim down the size of those "modules". In
other words, splitting may enforce defining a better API and isolation
components such as traverse or the file configuration facility, making it
easier to replace those components in the future.

* In splitting and reorganizing the code several modules have been found
that are actually _not_ used. Windows shortcuts for instance.

* The split development model accommodates very easily new optional modules
which may also be _included_ in a prepackaged ASDF -- easier configurability
and extension for "vendors" or "distributors". In particular one may add
asdf-ecl... asdf-sbcl... for the bits that are not portable (dumping images,
merging files...)

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/20100922/423d0474/attachment.html>