There is a rationale for the splitting of asdf.lisp.<br><br>* Sorry, but the excuse of searching for code in a file is lame :-) Would that also apply to any thousand lines code library?<br>
<br>* 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.<br>

<br>* 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).<br><br>* 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.<br>


<br>* 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.<br>

<br>* 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.<br>
<br>* In splitting and reorganizing the code several modules have been found that are actually _not_ used. Windows shortcuts for instance.<br><br>* 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...)<br>

<br>Juanjo<br><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com">http://juanjose.garciaripoll.googlepages.com</a><br>