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