Lisp file and/or ASDF dependency analysis; trying to load asdf-dependency-grovel

[Robert Goldman]

On 15 Dec 2022, at 14:48, Robert Dodier wrote:

> Robert, thanks for your reply. I have made some progress.
>
>>> Just performed compiling #<INSTRUMENTED-CL-SOURCE-FILE
>>> "test-serial-system" "package"> but failed to mark it done
>
>> It would help to get a backtrace here. I can't tell from this if the 
>> error is happening in ASDF or in ASDF-DEPENDENCY-GROVEL (which 
>> probably isn't maintained).
>
> The "failed to mark it done" is coming from ASDF. The ASDF version
> (bundled with SBCL) is, I think, 3.2.something. I tried it with
> Clozure CL, which has (on my system at least) ASDF 3.1.something, and
> the same operation succeeds. I guess I'm not too worried about it,
> since I now have a workaround, but I'm curious to know what's going on
> here.

FWIW, *both* of these are obsolete. The current release is 3.3.6 which 
you can get from the ASDF home page (at common-lisp.net)

I don't see any reason that 3.3.6 would fix the problem you see, but we 
can't debug old versions of ASDF.

It should be easy to install the new version of ASDF on any lisp if you 
grab the monolithic file and load it in your lisp .rc file
>
>> Also whose run-tests.sh are these? ASDF's tests or 
>> ASDF-dependency-grovel's?
>
> For the record, it's the run-tests.sh of asdf-dependency-grovel.
>
>> Again, it would help to have a backtrace from this circular 
>> dependency to help us get started (if you can share it -- I suppose 
>> your system could be private/proprietary).
>
> About the circular dependency, it's in Maxima's ASDF file. After
> puzzling over a backtrace (thanks for the hint) I figured out it's
> because :serial t is specified, and a module depends on something
> later in the .asd. I moved the offending module and that resolved the
> dependency error. Hurray!
>
>> I wonder if we should adopt asdf-dependency-grovel into the ASDF 
>> group on cl.net's GitLab? There's no guarantee that would result in 
>> active maintenance, though -- it should be obvious that I don't have 
>> a lot of cycles to spare...
>
> Well, I think that sounds like a good idea. I know developing new code
> is unlikely but it would be great to at least make any updates
> necessary to keep up with new ASDF versions.
>
> asdf-dependency-grovel seems like a really great idea -- I am hoping
> to use it to analyze dependencies in Maxima, which, as you may know,
> is an ancient and pretty large system ... If asdf-dependency-grovel
> didn't exist, I would have to reinvent some wheels.

Forking it into ASDF would make sense because then at least we could set 
up GitLab CI and identify when it does or does not work with the most 
up-to-date ASDF.

If you think this is a good idea, and would be willing to set up a fork 
of asdf-dependency-grovel, please contact off-list with your cl.net 
account (they are easy to get if you don't have one), and I can add you 
to the group. Then you would be able to fork A-D-G into the ASDF group. 
 From there I could set up the GitLab CI to run the tests automagically.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20221215/620b127c/attachment.html>