Re: c-basic-common-init
Alan Mackenzie writes:
It turns out I've had this problem before, and I found a note
I'd
made a year ago today. Mats Lidell pointed out that XEmacs can
only link up to the packages _after_ they've been through 'make
install', and that the start-up code can't parse the structure of
the package source directory.
I don't want to have to 'make install' for debugging my package,
Well, there is no alternative for a fresh start of XEmacs. I don't
understand why this design mistake was made[1], or why there has been
such resistance to changing it. (I've suggested /opt-style packages
that can run-in-place on a couple of occasions, but it's always been
vetoed.)
It should be possible to set up so that you can "make install" in your
cc-mode source and do the install directly to your installed
hierarchy, but it's not going to get better than that for a long time,
unless Mike has a change of heart. Nobody else knows the code well
enough. Sorry.
You could ask Mike if he has any suggestions. I don't; I just live
with the restriction, and do
make bindist \
&& pushd /usr/local/xemacs/xemacs-packages \
&& cat pkginfo/MANIFEST.$package | xargs rm \
&& tar xz $package-pkg.tar.gz
when I'm ready to test from a fresh XEmacs. (Actually it's a little
more complicated than that, I add a timestamp to the filename which
allows me to keep the tarballs around, and rollback to an earlier
version.)
May I suggest that the start-up code be enhanced to be able to cope
with either the installed or the source directory structure, and
Sure. I doubt anything will be done about it in 21.4, though you
could lobby Vin to install it if the code becomes available. But
probably that's way too big a change to be made in the stable line.
Sorry, again.
that with a bit of play to cope with the supplied path ending
either just "xemacs-packages" or "xemacs-packages/xemacs-packages".
No chance of that. It's unfortunate that Mike chose to make the hg
package top have the same name as the "regular" package hierarchy,
because the startup code cares about the name "xemacs-packages" (it
uses that name to identify the root of a regular package hierarchy).
Just rename the parent of the package hierarchy roots.
Footnotes:
[1] I understand why the current tree structure is supported: it
looks like an installed XEmacs 19, making the initial transition easy
for beta testers. What I don't understand is why no effort was made
to support run-in-place.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta