[Removing Erik and Alan from the CC who should see it on the armedbear list if they're interested/
On Mar 25, 2010, at 2:00 PM, Robert Goldman wrote:
On 3/25/10 Mar 25 -1:49 AM, Mark Evenson wrote:
On 3/25/10 7:34 AM, Faré wrote: […]
....
It would be perhaps cleaner to have the binary locations machinery of ASDF2 react to not being able to write to the Pathname derived from the location of the ".asd" file in an extensible manner. This might be useful for users of Lisps other than ABCL who don't have permission to write to the system ASDF location for instance. My current problem is that the :BEFORE for PERFORM specialized on COMPILE-OP SOURCE-FILE contains an ENSURE-DIRECTORIES-EXIST which by default is derived from the ".asd" Pathname. Is there a way to per-system customization of the output location?
How do you propose to do that?
Not sure, which is why I was floating the idea for comments, but if I can run a user-defined function after the .asd has been parsed to programatically implement the following, that might work. I need to read up on what is present in the currently defined mechanism.
Faré would it be possible/appropriate to take the core of find-system which does the work of loading the system (opening the file, interpreting it, etc.), and package it up as a generic function so that it would be possible for customizers to add :before, :after, and :around methods? Or, alternatively, for "in-house" ASDF extensions like Juanjo's, or a proposed ABCL jar extension, to provide additional "wrapper" methods that would leave :before, :after, and :around free for "outsiders"?
I've now spent some time understanding the output translations method in ASDF2, and think ABCL would be best served if we could add the ability to specify an arbitrary function as an output translation "destination". The extensions that Robert suggests would be interesting, but I don't have a current use case for them in application to ABCL.
Fare's suggestion that I use an output translation based on the jar pathname doesn't quite work, because in our current implementation, the pathname of the jar is stored in DEVICE, separate from the rest of the jar pathname. I extended PATHNAME-MATCH-P to match jars correctly, but I don't see a possible extension of TRANSLATE-PATHNAME. For purposes of discussion consider that a jar pathname has a namestring composed of "jar:file:DEVICE!/DIRECTORY/NAME.TYPE". This isn't quite the whole story: [See the design document for th gory details if interested][1]. Having the path of the jar file in DEVICE means that I cannot use TRANSLATE-PATHNAME to incorporate the path of the jar in the output translation to a plain file. The best I can do is
(initialize-output-translations '(:output-translations :ignore-inherited-configuration (#p"jar:file:/**/*.jar!/**/*.*" (:home #p"jar-files/**/*.*"))))
which "squashes" all of the output files under one directory irregardless of jar they are specified in , meaning that both "jar:file:/some/thing.jar!/package.lisp" and "jar:file:/a/completely/different.jar!/package.lisp" would have the same output translation.
[1]: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/doc/design/pathname...
So I would ask the ASDF developers to consider extending the output translation DSL to allow something like
(initialize-output-translations '(:output-translations :ignore-inherited-configuration (#p"jar:file:/**/*.jar!/**/*.*" :function SYS::ASDF-JAR-OUTPUT-TRANSLATE)))
or
(initialize-output-translations '(:output-translations :ignore-inherited-configuration (#p"jar:file:/**/*.jar!/**/*.*" :function (lambda (wildstring source) (pathname source)))))
Where the argument following :FUNCTION would either name a symbol for a function or a lambda expression that specifies a function that takes two arguments, the WILDCARD matched and the pathname of the SOURCE that matched. This function would return a pathname suitable for the output location.
I'm working on an implementation of this on your git version as a proof of concept, but haven't gotten much further than getting your output configuration to accept the new syntax. I assume that actually applying the function will be easy, but I am not sure.
And, is there a syntax to specify that a pathname matching a given pattern should have no output location, but should just load the source?
--
"A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."