On 2/6/11 Feb 6 -3:23 PM, Faré wrote:
On 5 February 2011 17:14, Juan Jose Garcia-Ripoll juanjose.garciaripoll@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