[asdf-devel] Minor simplification

Robert Goldman rpgoldman at sift.info
Sun Feb 6 22:01:57 UTC 2011


On 2/6/11 Feb 6 -3:23 PM, Faré wrote:
> On 5 February 2011 17:14, Juan Jose Garcia-Ripoll
> <juanjose.garciaripoll at googlemail.com> wrote:
>>> Please understand that all this is about not *hardcoding* in ASDF what the
>>> compiler should or should not do. All you are suggesting is about reader
>>> conditionalization (that means one ASDF file per compiler), hardcoding
>>> behavior based on externally defined flags (which may or may not exist at
>>> all in older or later releases), and other things that overcomplicate the
>>> problem.
>>
> Where is the behavior to be coded? Surely it must be coded somewhere.
> Is it unreasonable to upgrade ASDF when new code is required, and to change
> few boolean controls to select which branch of the code applies?
> 
>> Argghh this does not work at all. I did not realize that ASDF's compilation
>> now uses a temporary file name. That is really unfortunate because it means
>> we can not really wrap inside compile-file* and also not around
>> compile-file*, and we have to go back to the level of PERFORM.
>>
> Or perhaps we could factor ASDF to do renaming for all client methods
> in a more transparent way - problem being it would require
> invalidating existing extensions.

That might be nice --- we have been having some issues with protobuf and
ASDF 2, because of having a two stage process of generation of lisp from
protocol buffer and then fasl from lisp.  I have a few cases where this
happens, because it's easy to generate lisp from an abstract
specification language.  Hm...  This should almost be a FAQ.

cheers,
r




More information about the asdf-devel mailing list