[asdf-devel] [armedbear-devel] Patches for ABCL against asdf-1.641

[Mark Evenson]

[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/pathnames/jar-pathnames.markdown

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."