2011/10/17 Gábor Balázs gabalz@gmail.com:
I think the divergence is coming from the fact that I want a special functionality (package renaming) with a simple syntax and you want a general functionality which cannot be represented by a simple syntax. So it is a tradeoff between simple syntax and general functionality.
No. I want to keep asdf.lisp minimal, yet provide hooks for other people to write extensions that do what they need to do without making it a mess.
I am also writing those hooks with knowledge of how things are done or can be done in xcvb, which I believe follows a saner computation model, and which I hope will replace asdf someday.
An around-compile hook is general enough that 1- you can implement whatever you want on top 2- it encourages a sane approach to controlling compilation
Yet 3- it couldn't be done cleanly without a hook inside asdf.lisp.
Indeed, you could have your own cl-source-file subclass and override perform, but you'd have to either copy/paste code from the default perform method, or lose the functionality and experience bitrot when it changes. Or you could try an :around method around perform, but you wouldn't be able to filter the results of compile-file based on e.g. a check of whether compile-time side-effects verified some invariant of yours (see what I mean with fare-utils/molicle/). Or you could try to bind *compile-op-compile-file-function*, but systems that do that would interfere badly with each other, and possibly with lower-level settings from e.g. ECL.
As package renaming is already available in a "complex" way, providing another complex way won't improve on its popularity. If it would be possible just with a few more characters in an asd file, people might use it. Otherwise if they have to create different functions, classes in separate files for that, they just keep providing nicknames...
I invite you to write a asdf-package-renaming extension to asdf, that does what you need, by defining your own cl-source-file extension and/or (preferrably) by using this new around-compile mechanism. Note: if you use the :around-compile facility, you might want to include in your defsystem a :depends-on ((:version :asdf "2.017.18")).
But I am wondering how an asd file would look like with your scenario. Can you provide an example?
See the test .asd file in the attached patch. Instead of binding the *read-base* it could call a function that uses unwind-protect to locally rename packages.
Btw, I imagine before/after implemented in a setup/cleanup style, so if compilation fails, cleanup (after) still runs. So it is wrapped in an unwind-protect. So the before/after is nothing to do with generic functions in my view. It is just a wrapping around COMPILE-FILE.
Therefore, you need an :around function anyway. Then why not expose the complete functionality?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If it's not worth doing, it's not worth doing well — Donald Hebb