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?
Please, understand, I do not want to commit to a particular behavior right now. I do not know yet how I am going to code the bytecodes compiler, or if I will allow multiple variants or whether I will have something which is build-fasl-like in a third phase of development.
I want freedom on developing my ECL side of the code while preserving
compatibility and minimal intrusiveness. I do not want to have to come
here and ask for every single change every time I make different design choice, or
even worse, keeping track of versions. Pluggin in into ASDF should be
done from my own extensions (asdf-ecl and new compiler backends) and not by hardcoding behavior into ASDF
where it does not belong.
I think what I am suggesting is pretty reasonable.
1* COMPILE-FILE* right now has a very well defined purpose, (compile a single lisp file with error handlers) which I
believe should not be touched if it is going to be exported as a tool. Move back from method to function.
2* Right now the only ECL-dependent behavior is in PERFORM when applied on COMPILE-OP and on OUTPUT-FILES acting on the same operator. Get these changes away by default. 3* The ECL-specific part only makes sense and only is needed when combined when asdf-ecl.lisp, which itself only makes sense when used with the current C compiler. This can be moved to asdf-ecl.
4* Allow a simple way to plug into the compile-op actions. An :around method is too complicated because there may be more layers and using MOP is both nonportable, non-future proof, and a mess -- what methods to add, what to remove? bootstrapping problems, versioning...
Everything is atached to this email. Just one single hook (a special variable), removed all ECL-specific logic from asdf.lisp, and back into asdf-ecl.lisp, where it belongs, non-intrusively.