Hm, I like the idea of having multiple classes for cl-source-file objects. But I wouldn't do it through CLOS. Just playing around, something like this might be able to provide functionality to your problem.
(defsystem com.host.my-system (:serial t) (:depends-on ("system-1" "system-2") (:components ((:file "file1") (:file "file2" :class 1) (:file "file3" :class 2) (:file "file4" :class 1)) (:before-compile 1 #'(lambda (component) (do what you want))) (:after-compile 1 #'(lambda (component) (do what you want)))))
And class 0 could be the (unspecified) default. However, I would still prefer to have some kind of simplified notation for the local package renaming functionality as I think that is the most common. And I have no idea how difficult it is to put something like this into asdf as I am not familiar with its code...
`bg`
2011/10/16 Faré fahree@gmail.com
I have my function, which does the described job for me too. The point
here
is to offer this functionality in public on an easy, standard way.
Agreed.
Personally, I like to have a single defsystem sexp in the asd file, so I would prefer avoiding function definitions there.
Same here. However, I would even more prefer having one generic mechanism for all these similar issues (wrapping bindings and environment-setup side-effects around compilation), rather than every time having to invent a new ad-hoc mechanism for each possible binding or side-effect that one might conceivably want:
locally renaming packages binding *readtables* and other syntax-controlling variables handling warnings and other conditions proclaiming optimization settings saving code coverage information maintaining meta-data about compilation timings resetting gensym counters, PRNG seeds, etc., for determinism cheating the source-location and/or timestamping systems checking that some cleanup function was properly called etc.However to do that nicely, asdf should be refactored in a way described by Robert.
Not necessarily. It is often important to wrap code around compilation, as shown above, but after writing XCVB, it seems to be that it isn't so useful to have wrappers around subtrees of the build, unless you can somehow save the information to files after a build, and merge it from saved files when you skip the incremental compilation of a file that hasn't been modified. In other words, all the information should be inside the FASL or a complement to said FASL. Otherwise, whatever information you use is just going to make your build less deterministic, and you'll end up always building from clean anyway, at which point you might as well use a load list instead of asdf.
But I think it would be still nice to offer this (cheap) renaming functionality separately without some heavy syntax (wrapping the whole defsystem into a function seems to be heavy for me).
A more interesting question would be: why not do that as originally intended, by defining a proper CLOS subclass of cl-source-file? If it isn't fully satisfactory, what would be, and what variant of CLOS would it take? (Say, would SHEEPLE make things nicer?)
it is fairly easy to implement into the current mainstream asdf version it is easy to use, so CL library developers could easily eliminate the :nicknames options from the package definitions and use this instead
(they
should basically change only a few lines of code in the .asd and package.lisp files) unfortunately, it is not the most general solution, so the arbitrary function wrapping would not be provided this way
I feel the 2nd point very valuable, so I think it would worth doing...
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Voting for liberty is like raping for virginity. — Jim Davidson