rpgoldman at sift.info
Fri Oct 20 14:01:07 UTC 2017
This is a better summary than I gave. To summarize, loading UIOP
*exposes* an error that was always in the version of ASDF in QL/SBCL.
It's not a new problem with UIOP or ASDF. I think the issue is exposed
because UIOP is so high up in the dependency chain.
On 20 Oct 2017, at 0:25, Faré wrote:
> Dear Xach,
> I saw your blog post:
> There are no comments on your blog, so I'll just clarify things on the
> asdf-devel list:
> * The situation you describe is not at all a problem specific to uiop
> 3.3.0, or any other version of uiop. uiop.asd hasn't changed since
> 3.2.0, and the "issue" already existed before, and exists when there
> is no uiop.asd available but only the builtin uiop.
> * The situation you describe, where some libraries are loaded multiple
> times, is a bug in ASDF, that was fixed in 3.3.0 --- actually, fixing
> this situation and other related situations was the very reason why I
> had to teach ASDF about build phases, which lead to the big
> refactoring done in 3.3.0.
> * All build systems have to either face the issue of build system
> extension, or put their head in the sand and do the wrong thing. At
> least ASDF 3.3.0 does the right thing now, whereas earlier versions
> put their head in the sand as far as that issue was concerned. (I also
> know that Bazel has a proper solution, though it involves using a
> non-extensible DSL for extensions).
> * At least in that case, the issue is not too bad: just some system
> recompiled, that will also cause more recompilation the next time, but
> don't cause an infinite loop, just a waste of CPU time.
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
> In Italia i fascisti si dividono in due categorie:
> i fascisti e gli antifascisti. — Ennio Flaiano
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asdf-devel