Impact on modifying the current planning code (was Re: Plans for ASDF 3.3)
fahree at gmail.com
Thu May 4 15:08:34 UTC 2017
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
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
> 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
More information about the asdf-devel