>>> Tom Tromey <tromey@...> seems to think that:
>>>>>> "Eric" == Eric M Ludlam <eric@...> writes:
>Eric> ELPA may find it useful to use the `inversion.el' file that is
>Eric> in CEDET for version dependencies. I've found it helpful.
>I looked at inversion.el a while back, and while it does look good,
>I'm trying to keep package.el dependencies minimal. ATM I'm not even
>using the version comparison stuff in Emacs 22, instead rolling my own
>(lame) variant :(
>Eric> It looks like ELPA tries to do fancy stuff with autoload cookies.
>Yeah, it extracts them at install time. It also compiles the package.
>It sounds like CEDET will need extra care from package.el. That's
>fine, but it means package.el changes are needed -- so it will have to
>wait a bit until I'm actively hacking package.el again.
>In particular what I understood from your notes is that CEDET can't
>use the plain vanilla autoload extraction or byte-compile code.
>FWIW one (implicit) goal of ELPA is not to have Makefiles the like for
>pure elisp packages. I mean, for package maintainers I think this
>kind of thing is probably needed (to make the packages, for one :),
>but generally I don't see the need for this for end users. I think it
>is much friendlier to let them just point at a package and have it
>start working -- and the fewer host-side dependencies this involves,
>For autoload extraction, I think we could easily add an option to
>define-package to tell package.el not to do anything. That way a
>sophisticated package like CEDET could just supply its own activation
>Byte compilation is trickier. I want package.el to do this so that I
>can make it automatically recompile packages when Emacs is upgraded.
>I haven't looked at CEDET's build (yet), but I know that some other
>packages need some customization: fix the ordering of compilation,
>omit a file or two, etc. Would this sort of thing suffice for CEDET?
[ ... ]
Based on a different request, I checked in a tool that compiles CEDET
from w/in Emacs only in cedet-build.el. It only handles the Emacs
Lisp part. There are three kinds of targets it will build, including
autoload files, grammar files, and general Lisp files. Order is
important since the build process uses the tool it's compiling, so
compilation bootstrapping is fragile.
That build script will likely make it easier for package.el, but it
needs to be run in a fresh emacs like this:
emacs -q -l cedet-build.el -f cedet-build
and after it's built, you really need to exit Emacs so the compiled
versions can be loaded for performance reasons.
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net