Sorry, I had a typo, I didn't want to assume any relationship between system and package names. That is the role of the developer who writes the asd file.
So let take the following scenario:
Instead of having:
com.long-host.my-library.asd
(defsystem com.long-host.my-library :serial t :depends-on ("com.long-host.system-1" "com.long-host.system-2" "com.long-host.system-3") :components ((:file "package") (:file "file-1") (:file "file-2") (:module "module" :components ((:file "file-3"))))
package.lisp
(defpackage com.long-host.my-package (:use :cl :com.long-host.package-1) ...)
If I am lucky and I can use the :com.long-host.package-1 package (defined by com.long-host.system-1 library). If I cannot do it with :com.long-host.package-2, then I have to use fully qualified names in "file-1.lisp", "file2.lisp" and "file3.lisp" like com.long-host.package-2:some-function. Similarly let say I don't want to use :com.long-host.package-3 for some reason.
I would like to write something like this:
com.long-host.my-library.asd
(defsystem com.long-host.my-library :serial t :depends-on ("com.long-host.system-1" "com.long-host.system-2" "com.long-host.system-3") :compile-with-nicknames (("com.long-host.package-2" "p2") ("com.long-host.package-3" "p3")) :components ((:file "package") (:file "file-1") (:file "file-2") (:module "module" :components ((:file "file-3"))))
Then I can simply write p2:some-function in "file-1.lisp", "file-2.lisp" and "file-3.lisp".
I think as far as there is no easy way to do this, people will just define short nicknames for their packages, and the number of collisions will increase... That's why I think it would be useful, to stop this "habit"...
`bg`
2011/10/16 Robert Goldman rpgoldman@sift.info
On 10/16/11 Oct 16 -8:53 PM, Gábor Balázs wrote:
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.
I think the problem with doing this :before and :after of each component and operation is that it doesn't have sensible :around semantics. E.g., you can't easily use it to do something obvious like wrap a dynamic variable binding around the entire compilation of the system and then update that dynamic variable binding to communicate across individual compilations.
I also worry about this nicknaming idea because it seems to rely on assumptions about the package-to-system mapping that aren't articulated clearly yet.
Can you explain the use case more clearly so we understand why this is generally useful?
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 mailto: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 <mailto: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: 1. 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. 2. 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• http://fare.tunes.org > > _______________________________________________ > asdf-devel mailing list > asdf-devel@common-lisp.net <mailto: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 <mailto:asdf-devel@common-lisp.net> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel