[asdf-devel] :depends-on to load-system or require-system?

[John Morrison]

Hi All;

tl:dr - AFAICT post-version-2.26-ish versions of ASDF systems listed in
:depends-on are unconditionally loaded rather than required - ditto for
asdf:load-system.  If this is correct (both in intent and my
understanding), then how to create a GUI for quicklisp in McCLIM which can
quickload any system which :depends-on McCLIM?

Apologies in advance in the likely event this is Pilot Error.

Am trying to write a
gui<https://bitbucket.org/symbolicsimulation/com.symsim.oss.ql-gui>for
quicklisp.  Testing on various platforms (Raspberry Pi, linux/SBCL,
linux/CCL) with various vintages of ASDF produces differing behavior.  In
particular, quickloading a system which depends upon McCLIM from the
McCLIM-based gui screws up (I haven't tracked down the exact problem, but I
could understand why unconditionally reloading McCLIM while it's running
could get weird).

After some digging (and rebuilding various versions of SBCL up to 1.1.9), I
got as far as seeing asdf:load-system behavior diverging from 2.26 (SBCL
1.0.9) to both 2.32 (CCL 1.9) and 3.0.2 (both SBCL and CCL).  AFAICT 2.26
load-system does not unconditionally load an already-loaded system
(behaving like and perhaps redundant to asdf:require-system).  2.32 and
3.0.2 load-system unconditionally load systems, and require-system does
not.  I think I understand why the newer vintages do this.

The issue for me is loading systems that :depend-on McCLIM from inside a
McCLIM frame command.  In my naivety, I would think that the :depends-on
systems should be required rather than loaded (if you've patched them, say,
you wouldn't want the patch hammered).  For my own stuff, I guess I could
require prerequisite systems within the asd file rather than :depending-on
them, but this seems wrong (breaks introspection?) - so wrong I feel I may
be going about this entirely the wrong way.

Would anybody please be so kind as to throw some advice my way?

-jm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20130903/d701435b/attachment.html>