[asdf-devel] compile-with-nicknames
Gábor Balázs
gabalz at gmail.com
Mon Oct 17 02:39:48 UTC 2011
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 at 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 at sift.info
> > <mailto:rpgoldman at sift.info>> wrote:
> >
> > On 10/16/11 Oct 16 -4:52 PM, Faré wrote:
> > > 2011/10/16 Gábor Balázs <gabalz at gmail.com <mailto:gabalz at 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 at common-lisp.net <mailto:asdf-devel at common-lisp.net>
> > > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
> >
> >
> > _______________________________________________
> > asdf-devel mailing list
> > asdf-devel at common-lisp.net <mailto:asdf-devel at common-lisp.net>
> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20111016/95e5f9d7/attachment.html>
More information about the asdf-devel
mailing list