Including uiop and not asdf in a built application

Robert Goldman rpgoldman at
Tue Jan 16 03:52:30 UTC 2018

On 12 Jan 2018, at 22:00, Dave Cooper wrote:

> Hi (I'm not sure who is current lead maintainer, but hopefully the 
> group
> will have some wisdom),

I'm still the lead maintainer for the nonce.  I believe Faré would like 
to see a replacement who is able to give more time and energy to the 
task.  For that matter, I would, too!  But no one has stepped up yet.
> First of all, Happy New Year and thank you to whomever is monitoring 
> this
> list.  Your efforts are highly appreciated.
> Our build process for Gendl and GDL for the past several years has 
> involved
> using monolithic-compile-bundle-op to make concatenated fasls, then 
> loading
> these fasls into an empty image to create the final build.
> We do depend on (and include) uiop, but not asdf, in our final build
> product.
> In order to have uiop available separately for inclusion in the
> monolithic-compile-bundles, we have been putting a copy of the uiop/
> directory (of the same version as the ASDF we're using) into
> quicklisp/local-projects/.
> Some time between ASDF and ASDF 3.3.1, the function
> check-not-old-asdf-system got modified to add "uiop" to the test 
> (first
> line of the function). This results (in ASDF 3.3.1) in
> a same-version uiop not getting loaded at all into a
> monolithic-compile-bundle, even if the system of said
> monolithic-compile-bundle contains a dependency on uiop and uiop is
> available in quicklisp/local-projects/.
> For this reason, out-of-the-box  ASDF 3.3.1 was not working for our 
> build
> process. I have "fixed" the problem temporarily by modifying my local
> asdf.lisp to remove the "uiop" from the test, i.e. I've replaced
>    (or (not (member name '("asdf" "uiop") :test 'equal)) ....
> with
>    (or (not (member name '("asdf") :test 'equal)) ...
> as the first line of the defun check-not-old-asdf-system.
> Question: Is there a supported way to do what I'm trying to do, 
> without
> modifying the ASDF source code? Intuitively, it seems to me that we 
> should
> be able to include uiop in build products using
> monolithic-compile-bundle-op, without including asdf.

I am afraid I don't have much light to shine here.  It seems to me that 
we have an issue here that comes from using ASDF for two different 
purposes.  In the case of what I think of as "normal" ASDF usage, ASDF 
ensures that a currently running lisp image gets into a consistent state 
with respect to software systems, and can be kept in (or perhaps 
restored to) such a state as source code is modified.

The bundle operations do something that is substantially different.  
They are being used to *construct* a new and different Lisp image, I 
believe, and so comparing to the state of the running image may be 
wrong.  This seems like such a case: the state of the ASDF system and 
UIOP in the *running* image doesn't necessarily correspond to the state 
of those systems in the image you are constructing.  In that case, it 
seems to me that check-not-old-asdf-system may be simply inappropriate 
as a check in some (all?) bundle operations.  But I would be hard 
pressed to say when it is and is not appropriate.  E.g., presumably it 
is appropriate in image building, since any image one builds would 
include the current running ASDF.  But that argument does not seem to 
hold for bundles full of fasls or source code, does it?

I wonder if it is possible that we should move this check out of its 
current location, where it attempts to hide out-of-date versions of ASDF 
and UIOP from view.  Maybe we should instead make an installed version 
of ASDF visible to `locate-system` so that any out-of-date version will 
be shadowed that way, instead of needing to be hidden from 
`locate-system`, as it is now.

In one sense at least, Faré is right that I should be replaced as 
maintainer.  I have never used any of the bundle operations, and feel 
ambivalent about their inclusion into ASDF.  They crept in as a 
side-effect of supporting lisps that use the C compiler, but they are a 
*substantial* increase in the breadth and maintenance difficulty of 
ASDF.  I'm afraid I have neither the time nor the interest to carry that 
burden.  I would be happy to yield it to others.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the asdf-devel mailing list