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.
Best, r
On 20 Oct 2017, at 0:25, Faré wrote:
Dear Xach,
I saw your blog post: http://lispblog.xach.com/post/166534341423/uiop-330-problems
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• http://fare.tunes.org In Italia i fascisti si dividono in due categorie: i fascisti e gli antifascisti. — Ennio Flaiano