On 2/6/11 Feb 6 -3:23 PM, Faré wrote: > On 5 February 2011 17:14, Juan Jose Garcia-Ripoll > <[email protected]> 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 _______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
