[asdf-devel] :ASDF-DEPENDENCIES implemented

[Robert Goldman]

On 4/19/10 Apr 19 -1:01 PM, Faré wrote:
> I pushed Juanjo's patch for :ASDF-DEPENDENCIES as 1.704, except that I
> renamed the feature :SYSTEM-DEPENDENCIES. Maybe it should have been
> :SYSTEM-DEPENDS-ON. Ahem. You tell me what you think.
> 
> As for optional dependencies, I think things like
> ASDF-SYSTEM-CONNECTIONS are a walking nightmare, and horrible bugs
> waiting to happen. If you want to layer your system, just have
> foo-minimal or foo-core for the core functionality, and foo or foo-all
> for the whole system with all the dependencies. Trying to confuse the
> two under one name is but bugs waiting to happen.

I think that the test operation is the classic case where this method
fails.  The problem is that you want to specify /in the system to be
tested/ the test methods, the test-dependencies, etc., but you don't
want to force everyone who wants to use library X to install whatever
library X's developer thought was the cool test framework.

optional dependencies are kinda nasty, but less nasty than:

(when (find-system :nst)
  (pushnew :nst-tester *features*))

(defsystem foo
   #+nst-tester #+nst-tester
   :in-order-to ((test-op (test-op foo-tester)))
   ...)

#+nst-tester
(defsystem foo-tester
  :depends-on (nst-asdf foo)
  ....)

Is there a cleaner way to handle this?

Seems like a DOC-OP is almost certain to involve the same kind of
nastiness....

> 
> Finally, considering the naming of things in the target package before
> it has been defined -- cl-launch usually stores forms like that as a
> string to be read and eval'ed after the system has been loaded. XCVB
> on the other hand has a call procedure that takes package + symbol
> designators as arguments to specify what to funcall after the package
> is ready.

Adding something like this to ASDF would be very nice.  People shouldn't
really have to do that (funcall (intern ...)) guff every time and, if we
were to do this once, we could get it right once (and automagically
handle the mlisp issues, while we are at it).

Best,
r