hY Fare and Robert,<br><br>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. Personally, I like to have a single defsystem sexp in the asd file, so I would prefer avoiding function definitions there. I haven't met any situation before when something serious had to be done around a compilation, but you are probably right and wrapping arbitrary functions is a useful functionality. However to do that nicely, asdf should be refactored in a way described by Robert. 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).<br>

<br>So my function walks along the whole asdf component tree and set the :before and :after for each (non-module) component. I had to do this way just because the fact you described (I guess). But I was thinking instead of putting this functionality around the compile-file call itself inside asdf. So to apply this immediately to the whole component tree (to each compilation unit). I think it is not a restriction with renaming. At least I cannot imagine a reasonable scenario when one wants to use different nicknames of the same package for different asdf modules.<br>

<br>So as I see this renaming functionality has the following properties:<br><ul><li>it is fairly easy to implement into the current mainstream asdf version</li><li>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)<br>

</li><li>unfortunately, it is not the most general solution, so the arbitrary function wrapping would not be provided this way</li></ul>I feel the 2nd point very valuable, so I think it would worth doing...<br><br>`bg`<br>

<br><br><div class="gmail_quote">On Sun, Oct 16, 2011 at 4:11 PM, Robert Goldman <span dir="ltr"><<a href="mailto:rpgoldman@sift.info">rpgoldman@sift.info</a>></span> wrote:<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">On 10/16/11 Oct 16 -4:52 PM, Faré wrote:<br>
> 2011/10/16 Gábor Balázs <<a href="mailto:gabalz@gmail.com">gabalz@gmail.com</a>>:<br>
>> But there would be a nicer way, and this is the proposal. What about a new<br>
>> asdf option (eg :compile-with-nicknames), which could look like something<br>
>> this?<br>
>><br>
>> (defsystem my-system<br>
>>   :depends-on ("package-1" "package-2" "package-3" ...)<br>
>>   :compile-with-nicknames (("package-1" "pckg-1")<br>
>>                            ("package-3" "pckg-3"))<br>
>>   :components (...))<br>
>><br>
>> I think this approach nicely works in a "clear" environment for non-parallel<br>
>> compilation when there are no insane nickname requests.<br>
>> The "clear" environment assumption can be relaxed to say that the user<br>
>> hasn't defined any nicknames which causes collisions for any necessary<br>
>> compilations.<br>
>><br>
>> Or if you know a better way to handle this problem, I would be happy to hear<br>
>> about that...<br>
<br>
</div>I think there is a better way to solve this problem, but it is an ASDF3 method.<br>
The basic idea is as follows:<br>
<br>
1.  ASDF currently works by developing a LINEAR plan for performing an<br>
operation.  Here's an example:<br>
<br>
CL-USER> (asdf:operate 'asdf:load-op :murphy-ltk-demo)<br>
#<ASDF:LOAD-OP NIL @ #x1000d42f82><br>
((#<ASDF:LOAD-OP NIL @ #x1000d57312><br>
  . #<ASDF:CL-SOURCE-FILE "ltk" "ltk">)<br>
 (#<ASDF:LOAD-OP NIL @ #x1000d57312> . #<ASDF:SYSTEM "ltk">)<br>
 (#<ASDF:LOAD-OP NIL @ #x1000d62f32><br>
  . #<ASDF:CL-SOURCE-FILE "murphy-ltk-demo" "package">)<br>
 (#<ASDF:COMPILE-OP NIL @ #x1000d62f52><br>
  . #<ASDF:CL-SOURCE-FILE "murphy-ltk-demo" "ltk-demo">)<br>
 (#<ASDF:COMPILE-OP NIL @ #x1000d62f52><br>
  . #<ASDF:SYSTEM "murphy-ltk-demo">)<br>
 (#<ASDF:LOAD-OP NIL @ #x1000d42f82><br>
  . #<ASDF:CL-SOURCE-FILE "murphy-ltk-demo" "ltk-demo">)<br>
 (#<ASDF:LOAD-OP NIL @ #x1000d42f82><br>
  . #<ASDF:SYSTEM "murphy-ltk-demo">))<br>
<br>
Inspecting this plan reveals the problem: the operation COMPILE-OP on<br>
#<ASDF:SYSTEM "murphy-ltk-demo"> is not done AROUND the compilation operations<br>
on the component files, but AFTER them.<br>
<br>
2.  A possible solution would be to restructure the plans so that they are<br>
TREE-SHAPED, instead of linear.  So that there would be an operation that<br>
CONTAINS the compile-ops of the individual systems.<br>
<br>
Then, instead of the "plan interpreter" component of ASDF just being a MAP, it<br>
would be a tree-mapper.<br>
<br>
I think that this is in some sense The Right Thing.  The only problem is that<br>
the LOAD-OP is not "convex" in some sense.  Instead, there is loading of files<br>
done *during* the compilation.  So if we were to do this, wrapping something<br>
around the LOAD-OP might have counterintuitive results.<br>
<br>
Note also that I believe that we would have to keep the original, odd semantics<br>
of the operations on systems, and add a new operation, for backwards<br>
compatibility.  So we might have COMPILE-COMPONENT-OP or something.<br>
<br>
Cheers,<br>
<div class="im">r<br>
<br>
>><br>
> Dear Gábor,<br>
><br>
> you describe a common problem and a shared frustration of many CL developers.<br>
> However, the problem is not limited to package nicknames, and instead<br>
> I would prefer something more general:<br>
> the ability to wrap something around compilation,<br>
> essentially an advice around compile-file*.<br>
> I recently added this feature to xcvb, so that it may compile ironclad,<br>
> that uses such a wrapper (an :around method on perform)<br>
> to bind the *readtable* and muffle some warnings around compilation.<br>
><br>
> And so, I propose something more like:<br>
><br>
> (defun call-with-my-nicknames (thunk)<br>
>   (with-package-nicknames<br>
>     (("package-1" "pckg-1")<br>
>      ("package-3" "pckg-3"))<br>
>     (funcall thunk)))<br>
><br>
> (defsystem my-system<br>
>   :depends-on ("system-1" "system-2" "system-3" ...)<br>
>   :around-compile call-with-my-nicknames<br>
>   :components (...))<br>
><br>
> What do you think?<br>
><br>
> Of course, you'd have to use ASDF 2.018 or later for that.<br>
> Or maybe it's time to call it ASDF 2.18 instead?<br>
><br>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org" target="_blank">http://fare.tunes.org</a><br>
><br>
</div>> _______________________________________________<br>
> asdf-devel mailing list<br>
> <a href="mailto:asdf-devel@common-lisp.net">asdf-devel@common-lisp.net</a><br>
> <a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel</a><br>
<br>
<br>
_______________________________________________<br>
asdf-devel mailing list<br>
<a href="mailto:asdf-devel@common-lisp.net">asdf-devel@common-lisp.net</a><br>
<a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel</a><br>
</blockquote></div><br>