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
