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