Impact on modifying the current planning code (was Re: Plans for ASDF 3.3)

[Faré]

Dear Mark,

thanks for your request. I'm not sure I understand how your ASDF
dependencies do or don't map to MVN entities, though. I also don't
understand the maven model very well.

> Questions for consideration by the ASDF community:
>
> 1.  As I understand it, my problem doesn't have the problems of
>     redefining ASDF behavior during ASDF's load phase that Faré wishes
>     to eliminate in asdf-3.3.  If I were to slog through asdf-3.2.x to
>     implement the planning which I need would such an effort be
>     impacted in any way that you can foresee by what you need to change
>     for asdf-3.3?
>
If you're going to go deep inside ASDF's planning code, I would
strongly recommend starting off the 'plan' branch (due to be committed
in ASDF 3.3) rather than off 3.2, as there was significant refactoring
and merging would be a huge pain.

Also, if some of your dependencies are from defsystem-depends-on, you
*definitely* need to start off the 'plan' branch.


> 2.  Does anyone know if there an existing analogy for the ASDF:MVN
>     component in an ASDF extension that I could profitably study?
>     Currently, ABCL-ASDF hackishily neuters the ASDF:COMPONENT
>     association with a pathname, mainly because in the current
>     implementation a given ASDF:MVN component results in one or more
>     jar archives.  Does creating additional ASDF:MVN (a subclass of
>     ASDF:COMPONENT) instances in the in-memory ASDF that aren't
>     reflected in an *.asd file raise any problems that anyone is aware
>     of?
>
The current ASDF model is that every component has only one pathname,
though that pathname can be NIL, or can be a directory. If you need
multiple files, you can create multiple components indeed.

I don't understand what an MVN component is or does, but I don't see
any problem a priori with having multiple of them. Is it supposed to
represent (a) a dependency on an external maven package? Or is it
supposed to represent (b) a jar that is included as pre-built in the
current source? Or (c) the ability to build a jar from source in the
current system, that can then be pushed to maven?

In case (a), it probably should be a special subclass of SYSTEM. In
case (b) a component with a single file pathname should be fine. In
case (c) I would probably also have some subclass of SYSTEM do it, and
use one or many secondary systems.


> 3.  In the last few months, I think I remember that there has been
>     discussion around the possible use of ASDF to locate and download
>     shared objects for CFFI definitions (or maybe this was within the
>     CFFI community?).  The ABCL-ASDF case is a little simpler in that
>     the needed Maven binary objects are identical, unlike the CFFI
>     problem which has per-operating systems and (possibly) per-dynamic
>     linker implementation dependencies.  But still, as I remember the
>     outcome of that discussion, the general feeling was that such a
>     mechanism does not belong in ASDF.  Does the ASDF cognoscenti
>     think that what I am proposing here for ABCL-ASDF also seem to be
>     "too much"?  Note, that ABCL-ASDF will only ever work on ABCL
>     (unless, of course, we get another JVM CL implementation), and as
>     such, is intended to be written as an ASDF extension that should
>     have no impact on other's usage of ASDF.  Still, what has been
>     implemented (and what I am proposing), seems to violate Faré's
>     description of ASDF as a build system that should only deal with
>     Common Lisp artifacts.
>
I don't remember any discussion about downloading CFFI shared objects
(though I have vague recollections of discussions about cl-test-grid
and/or Quicklisp doing automatic installation of Ubuntu packages or
such.)

> Thanks for the attention and the solid re-engineering of ASDF,
Thanks for your appreciation.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Anyone who says he can see through women is missing a lot. — Groucho Marx