ASDF 3.3 is confused by misnamed secondary systems

Bug #1739514 reported by Faré on 2017-12-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

It looks like ASDF 3.3 dislikes misnamed secondary systems more than intended, and that these systems cause dependency confusion and/or spurious rebuilds instead or merely warnings (which are explicitly intended).

See for instance, slynk-mrepl vs slynk/mrepl in

Faré (fahree) wrote :

A simple system in quicklisp that fails this way is cl-logic.

Faré (fahree) wrote :

Note that if it were a simple circular dependency, it would have just
broken the build and be very visible and I'd have caught it last year.

Without having looked at the code or tried to debug it yet, my working
hypothesis is that having "foo" in "foo.asd" depend on "bar" also
defined in "foo.asd" causes dependency from (define-op "foo") to
(define-op . "bar"), which is always in need of build
(at least starting at the next rebuild) because
there is no "bar.asd" and the associated timestamp is therefore NIL.
If that is correct, the backward-compatible solution would be to make sure
that "bar" remembers that it was defined in "foo.asd", so that it gets the
timestamp from "foo.asd", and the next time around, if there is no
up-to-date "bar.asd", ASDF falls back on looking at the previously
loaded "foo.asd" or a more up-to-date version of it.

PS: Note that if "bar" is defined in both "foo.asd" and "bar.asd" you'll
still have a mighty bug. Therefore people should still fix their code
to properly name secondary system, ASDF should still issue a warning
when they are misnamed, and this warning should still be upgraded to a
cerror then an error when all of Quicklisp is fixed (>300 systems).

Faré (fahree) wrote :

Next interactive ASDF debugging session will be on Tuesday January 2nd 2018 at 14:00 EST (19:00 UTC). Send me a private email to be added to the Google Calendar event with a Hangout invitation.

Faré (fahree) wrote :

The debugging session made progress but was ultimately unsuccessful at fixing the issue.
The root cause seems to be that operations on "quine-mccluskey" ultimately depend on
(define-op . "quine-mccluskey") which is never performed because it's not *really* a primary system,
and so everything that depends on the system "quine-mccluskey" end up being recursively flagged as never done.

The solution is probably to distinguish between "syntactic" primariness (foo vs foo/bar) and "semantic" primariness (foo in foo.asd vs bar in foo.asd) at all the right places.

Faré (fahree) wrote :

Opening for a follow-up to this bug.

Faré (fahree) wrote :

Manual test that the problem is fixed:

(load "~/quicklisp/setup") ;; using a 2017 version of Quicklisp
(load-system :cl-logic) ;; load it once
(plan-actions (nth-value 1 (operate 'load-op "cl-logic"))) ;; load it a second time

If the problem is fixed, the last form return NIL as there's nothing to do.

If the bug is still present, it returns a long list the first element of which is:
(#<DEFINE-OP > . #<SYSTEM "quine-mccluskey">)
but quine-mccluskey is semantically a secondary system (though its name is that of a non-existent primary system), and this DEFINE-OP is invalid and shouldn't be there.

Faré (fahree) wrote :
Changed in asdf:
assignee: nobody → Faré (fahree)
status: New → Fix Committed
Changed in asdf:
status: Fix Committed → Fix Released
milestone: none → 3.3.2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers