[asdf-devel] compile-with-nicknames

[Gábor Balázs]

Hm, I like the idea of having multiple classes for cl-source-file objects.
But I wouldn't do it through CLOS.
Just playing around, something like this might be able to provide
functionality to your problem.

(defsystem com.host.my-system
  (:serial t)
  (:depends-on ("system-1" "system-2")
  (:components ((:file "file1")
                (:file "file2" :class 1)
                (:file "file3" :class 2)
                (:file "file4" :class 1))
  (:before-compile 1 #'(lambda (component) (do what you want)))
  (:after-compile 1 #'(lambda (component) (do what you want)))))

And class 0 could be the (unspecified) default.
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.
And I have no idea how difficult it is to put something like this into asdf
as I am not familiar with its code...

`bg`


2011/10/16 Faré <fahree at gmail.com>

> > 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.
> Agreed.
>
> > Personally, I like to have a single defsystem sexp in the asd file, so I
> > would prefer avoiding function definitions there.
> Same here. However, I would even more prefer having one generic mechanism
> for all these similar issues (wrapping bindings and environment-setup
> side-effects around compilation), rather than every time having to invent
> a new ad-hoc mechanism for each possible binding or side-effect that one
> might conceivably want:
>
>        locally renaming packages
>        binding *readtables* and other syntax-controlling variables
>        handling warnings and other conditions
>        proclaiming optimization settings
>        saving code coverage information
>        maintaining meta-data about compilation timings
>        resetting gensym counters, PRNG seeds, etc., for determinism
>        cheating the source-location and/or timestamping systems
>        checking that some cleanup function was properly called
>        etc.
>
> > However to do that nicely, asdf should be refactored in a way
> > described by Robert.
> Not necessarily.
> It is often important to wrap code around compilation, as shown above,
> but after writing XCVB, it seems to be that it isn't so useful
> to have wrappers around subtrees of the build, unless you can somehow
> save the information to files after a build, and merge it from saved
> files when you skip the incremental compilation of a file that hasn't
> been modified. In other words, all the information should be inside
> the FASL or a complement to said FASL. Otherwise, whatever information
> you use is just going to make your build less deterministic,
> and you'll end up always building from clean anyway, at which point
> you might as well use a load list instead of asdf.
>
> > 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).
> >
> A more interesting question would be:
> why not do that as originally intended,
> by defining a proper CLOS subclass of cl-source-file?
> If it isn't fully satisfactory, what would be,
> and what variant of CLOS would it take?
> (Say, would SHEEPLE make things nicer?)
>
> > 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...
> >
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
> http://fare.tunes.org
> Voting for liberty is like raping for virginity. — Jim Davidson
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20111016/6f87cacc/attachment.html>