OK, I'm setting the day and time for the next ASDF debugging session to Tuesday January 2nd 2018 at 14:00 EST (19:00 UTC). Please send me a private email if you can make it, I'll add you to a Google Calendar event with a Hangout invitation.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When it comes to giving, some men stop at nothing. — Saul Gorn On Wed, Dec 27, 2017 at 6:06 PM, Faré <fah...@gmail.com> wrote: > On Wed, Dec 27, 2017 at 10:33 AM, Robert Goldman <rpgold...@sift.info> wrote: >> On 4 Dec 2017, at 21:56, Faré wrote: >>> https://bugs.launchpad.net/asdf/+bug/1739514 >>> Basically, ASDF fails spuriously rebuilds misnamed secondary systems >>> and/or things that depend on them, instead of just issuing a warning >>> as intended. >> >> Another editing query here. Looks like it might be either "ASDF fails to >> rebuild" or "ASDF spuriously rebuilds misnamed..." >> > Yes, it's "ASDF spuriously rebuilds misnamed...". > > 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 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. > > 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).