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