Including uiop and not asdf in a built application

Robert Goldman rpgoldman at sift.info
Tue Jan 16 20:26:23 UTC 2018


On 16 Jan 2018, at 14:17, Faré wrote:

>> :Robert
>> 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?
>>
>
> Well, since at least on most implementations, building the fasls
> involve loading the code in the current image, there isn't much leeway
> by which asdf could afford not to use the same
> check-not-old-asdf-system function. A future version of ASDF that
> seriously supports cross-compilation might, but we're not quite there
> yet (see the TODO for hints, if you're interested in making it
> happen).

Am I correct in thinking that Dave's way of building monolithic bundles 
of either fasls or source code are, at least potentially, a baby version 
of cross-compilation?  It seems like these are interesting 
*specifically* because they could be loaded into *different* images 
(otherwise, it's not clear to me why it would be better to build a 
monolithic FASL than just build an image).

In that case, since this would effectively be cross-compilation (albeit 
a trivial case of it), it's not surprising that the logic for dealing 
with built-in dependencies like ASDF can go awry.

In which case delivering with Docker might be the better approach! ;-)

Best,
r
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20180116/7d24c970/attachment-0001.html>


More information about the asdf-devel mailing list