My recommendation is to not use reader conditionals, but instead use asdf/find-system:register-preloaded-system

Quicklisp will preempt any preloaded-system, but if that's what you want to avoid, my recommendation is to push the equivalent of the sysdef-preloaded-system-search before quicklisp's equivalent, but after the source-registry or the quicklisp local project search. Ahem. This can be tricky indeed.

And yes, if you don't ship with asdf and/or quicklisp and/or a way to load them that will actually be used, you lose. That said, I don't know about quicklisp, but I see no reason against pre-loading asdf, beside the slight increase in heap size: it's not going to hurt if it's not used, and it is designed to be able to upgrade itself and avoid downgrading itself, so that should be safe.

Speaking of which, currently, upgrades unregister loaded systems, though they probably shouldn't if the upgrade was from a recent-enough version where the class definitions and generic function definitions haven't changed in incompatible way. Robert: you might want to look into that, though doing it right requires a lot of testing. I suppose ASDF 2.27 would be the oldest fully compatible version at the time being.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you think you can do a thing or think you can't do a thing, you're right. — Henry Ford

On Sat, Dec 7, 2013 at 10:57 PM, Robert P. Goldman rpgoldman@sift.info wrote:

Dave Cooper wrote:

...

Hi,

Is stuff like the following advised/recommended?

;;;;; (asdf:defsystem #:robot :description "The Gendl™ Simplified Android Robot example " ... :depends-on (#-gendl :gendl) ... ) ;;;;;;

The scenario is that we ship a pre-built Gendl image which has no asdf or Quicklisp in it (but does, of course, have :gendl included in *features).

Downstream user is then free to load Quicklisp and start pulling in libraries. But if they pull a library (or application, like :robot), which normally should depend-on :gendl, then we don't want it trying to reload the whole gendl system, since it's already built in.

I know this was discussed here briefly around the launch of 3.0.3 but I'm still not completely clear on how it should work. If we don't include ASDF and Quicklisp at all in our pre-built image, then I don't see any way for us to tamper with e.g. asdf's registry search functions. I guess the only way to do that would be to provide a custom function for installing Quicklisp and ASDF -- but we have no guarantee that the user will actually follow our function and not simply try to install Quicklisp according to the instructions at quicklisp.org http://quicklisp.org.

I think it's fair to say that there are differences of opinion about this.

One school of thought would deprecate these, favoring a declarative syntax for ASDF:DEFSYSTEM. They wouldn't like such use of reader macros because it "hides" information from ASDF.

I am of a more pragmatic school that thinks these are fine. While I like declarative systems when possible, I'm not convinced that they are always realizable. I have a case very similar to yours where I have done exactly the same thing and put a #-<system> <system> in :depends-on, because ASDF does not correctly detect that <system> need not be reloaded in the prebuilt image we have. It's particularly an issue for us since the system in question *cannot* be loaded twice: if you attempt to do so, it compromises the state of the lisp image so that it is no longer usable.

cheers, r