11:07 a.m.
Whats wrong with this picture? (cut and pasted from output of 'make' with
'EMACSDEBUGPATHS=1'):
./xemacs -nd -no-packages -batch -l /home/valdis/src/xemacs-21.5/src/../lisp/loadup.el
dump
Loading /home/valdis/src/xemacs-21.5/src/../lisp/loadup.el...
Using load-path (/home/valdis/src/xemacs-21.5/lisp)
Using module-load-path (/home/valdis/src/xemacs-21.5/modules)
Loading very-early-lisp...
Loading /home/valdis/src/xemacs-21.5/lisp/dumped-lisp.el...
Loading /home/valdis/src/xemacs-21.5/lisp/backquote.elc...
Loading /home/valdis/src/xemacs-21.5/lisp/bytecomp-runtime.elc...
Loading /home/valdis/src/xemacs-21.5/lisp/find-paths.elc...
Loading /home/valdis/src/xemacs-21.5/lisp/packages.elc...
Loading /home/valdis/src/xemacs-21.5/lisp/setup-paths.elc...
Loading /home/valdis/src/xemacs-21.5/lisp/dump-paths.elc...XEmacs thinks the roots of its
hierarchy are:
("/home/valdis/src/xemacs-21.5/")
arguments:
roots: ("/home/valdis/src/xemacs-21.5/")
user-init-directory: "~/.xemacs"
inhibit-packages: (early late last)
inhibit-site-lisp: t
debug-paths: t
called-early: t
configure-package-path:
nil
early-packages and early-package-load-path:
nil
nil
late-packages and late-package-load-path:
nil
nil
last-packages and last-package-load-path:
nil
nil
lisp-directory:
"/home/valdis/src/xemacs-21.5/lisp/"
mule-lisp-directory:
"/home/valdis/src/xemacs-21.5/lisp/mule/"
module-directory:
"/home/valdis/src/xemacs-21.5/modules/"
site-module-directory:
nil
Loading /home/valdis/src/xemacs-21.5/lisp/subr.elc...
... <lots of lines of output deleted>
Loading site-load...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name xemacs
So then I go to run it:
[~/src/xemacs-21.5]2 src/xemacs -q
emacs-roots:
("/home/valdis/src/xemacs-21.5/")
arguments:
roots: ("/home/valdis/src/xemacs-21.5/")
user-init-directory: "~/.xemacs/"
inhibit-packages: nil
inhibit-site-lisp: nil
debug-paths: t
called-early: nil
configure-package-path:
nil
early-packages and early-package-load-path:
nil
nil
late-packages and late-package-load-path:
nil
nil
last-packages and last-package-load-path:
nil
nil
lisp-directory:
"/home/valdis/src/xemacs-21.5/lisp/"
mule-lisp-directory:
"/home/valdis/src/xemacs-21.5/lisp/mule/"
(for comparison, my still-working xemacs from a while ago outputs:
late-packages and late-package-load-path:
("/usr/local/lib/xemacs/mule-packages/"
"/usr/local/lib/xemacs/xemacs-packages/")
("/usr/local/lib/xemacs/mule-packages/lisp/"
"/usr/local/lib/xemacs/mule-packages/lisp/edict/"
"/usr/local/lib/xemacs/mule-packages/lisp/egg-its/"
<tons of output excluded>
Looks to me like the -no-packages on the undump caused this code in
lisp/dump-paths.el to misfire and undump a xemacs.dmp with no packages path:
(apply #'(lambda (early late last)
(setq early-packages (and (not (memq 'early inhibit-packages))
early))
(setq late-packages (and (not (memq 'late inhibit-packages))
late))
(setq last-packages (and (not (memq 'last inhibit-packages))
last))
)
Is this a --pdump only issue? Does it work for others?
It's been a *bad* night - between this and trying to get CVS 1.11.1p1 to
build under Digital Unix ('make check' bombed - turned out it was comparing
the version to a regexp '[0-9.]*' and the 'p' made it blow chunks).
/Valdis (who has had his fill of "how the <bleep> did it work for
anybody"
problems tonight. It's 6AM, time to find some breakfast)
6:51 a.m.
>>>> "Valdis" == Valdis Kletnieks
<Valdis.Kletnieks(a)vt.edu> writes:
Valdis> Whats wrong with this picture? (cut and pasted from output
Valdis> of 'make' with 'EMACSDEBUGPATHS=1'):
Nothing. This is the way Michael Sperber thinks it should be. There
was a thread on this a while back. The solutions are easy:
1. Add --package-path=/usr/local/lib/xemacs to your ./configure args.
2. Install XEmacs in the normal way and run from there.
If either of those doesn't work, I definitely want to hear from you.
Valdis> Looks to me like the -no-packages on the undump caused
Valdis> this code in lisp/dump-paths.el to misfire and undump a
Valdis> xemacs.dmp with no packages path:
-no-packages is a run-time only issue. Here it's used to prevent
pollution of binaries with information about the build environment.
Valdis> Is this a --pdump only issue? Does it work for others?
No, and no. I'm not sure why the list is not full of enraged
people.:) At this point it should not be possible to run in-place
without an explicit spec (EMACSPACKAGEPATH at run time or
--package-path at build time) for the root of the packages hierarchy,
or a packages hierarchy rooted at the build root.
Michael argues (more or less) that XEmacs should have only one ROOT
such that the executable is $ROOT/bin/xemacs or $ROOT/src/xemacs, and
that the packages hierarchies should be rooted in $ROOT/*-packages for
run-in-place, or $ROOT/lib/xemacs/*-packages for an installed XEmacs.
This is the admin-centric view.
The people who get upset about the situation generally feel that the
version-specific root (ie, found relative to $ROOT/{bin,src}/xemacs)
is one thing, and the packages root something else. They feel that
since XEmacs knows where it will be installed (according to --prefix),
it should look there by default for the packages root. This is the
tester-centric view. :-)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
8:13 a.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Stephen> Michael argues (more or less) that XEmacs should have only one ROOT
Stephen> such that the executable is $ROOT/bin/xemacs or $ROOT/src/xemacs, and
Stephen> that the packages hierarchies should be rooted in $ROOT/*-packages for
Stephen> run-in-place, or $ROOT/lib/xemacs/*-packages for an installed XEmacs.
Stephen> This is the admin-centric view.
Not quite: the startup code allows arbitrarily many roots. The
problem is that XEmacs needs to recognize these roots somehow, and in
many installations (say "/usr/local"), they are conflated with a lot
of other software, so it makes some sanity checks to ascertain a
directory is indeed an installation root. Having only the package
hierarchies there presently doesn't qualify.
It's been argued that the sanity checks do the wrong thing, i.e. they
don't recognize legitimate roots. This is probably true, and at the
time I rewrote the code for this, I merely imitated the old behavior.
I've changed it once, but I guess I need to change it again so that
people who have XEmacs roots containing *only* package hierarchies
have an easy way to mark them as such.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
11:04 p.m.
Michael Sperber [Mr. Preprocessor] wrote:
>>>>>"Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>>>
Stephen> Michael argues (more or less) that XEmacs should have only one ROOT
Stephen> such that the executable is $ROOT/bin/xemacs or $ROOT/src/xemacs, and
Stephen> that the packages hierarchies should be rooted in $ROOT/*-packages for
Stephen> run-in-place, or $ROOT/lib/xemacs/*-packages for an installed XEmacs.
Stephen> This is the admin-centric view.
Not quite: the startup code allows arbitrarily many roots. The
problem is that XEmacs needs to recognize these roots somehow, and in
many installations (say "/usr/local"), they are conflated with a lot
of other software, so it makes some sanity checks to ascertain a
directory is indeed an installation root. Having only the package
hierarchies there presently doesn't qualify.
It's been argued that the sanity checks do the wrong thing, i.e. they
don't recognize legitimate roots. This is probably true, and at the
time I rewrote the code for this, I merely imitated the old behavior.
I've changed it once, but I guess I need to change it again so that
people who have XEmacs roots containing *only* package hierarchies
have an easy way to mark them as such.
If you're in that neighborhood, please allow for this situation.
I have both i686-pc-cygwin and i586-pc-win32 versions and I wish to have the *minimum* of
duplication. Especially, I do not want to have all the lisp plus the packages in two
places.
My tree looks like:
[\CYGWIN]/usr/local <== My --prefix
/bin/i686-pc-cygwin/xemacs [copy or symlink]
/bin/i586-pc-win32/xemacs.exe
/lib/xemacs/etc <== I think because of a quirk in pui
/lisp [empty]
/info
/site-lisp
/site-packages
/xemacs-packages
/lib/xemacs-21.4.6
/i586-pc-win32/ DOC
/ various .exe's
/i686-pc-win32/ DOC
/ exe's
/lisp
/etc, etc, etc
Personally, I'd just as soon move this up to /usr/local/xemacs/xemacs-v.e.r
and leave the /lib/ out of it. But tradition is tradition.
I need an $EMACSPACKAGEPATH for this to work - regretable but I can live with it.
I also have persistant problems with auto-autoloads that are "already loaded."
I've commented on that but I'm told it's a "normal" bug.
The package download system wants to put things in /usr/local/lib/xemacs/pkgname vice.
/usr/local/lib/xemacs-packages/pkgname
so I wind up doing a manual step after each package update - serious pita.
--
David A. Cobb, Software Engineer, Public Access Advocate
"By God's Grace I am a Christian man, by my actions a great sinner." -- The
Way of a Pilgrim; R. M. French, tr.
Life is too short to tolerate crappy software.
.
6:56 a.m.
>>>> "David" == David A Cobb
<superbiskit(a)cox.net> writes:
David> I have both i686-pc-cygwin and i586-pc-win32 versions and I
David> wish to have the *minimum* of duplication.
David> Especially, I do not want to have all the lisp plus the
David> packages in two places.
Sorry, the core Lisp has to go in two places. Different versions are
typically not API compatible internally. We moved everything we could
justify out to the packages, and there are persistent grumbles from
developers that X Y or Z "needs" to be in core.
You should need only one copy of the packages.
David> Personally, I'd just as soon move this up to
David> /usr/local/xemacs/xemacs-v.e.r and leave the /lib/ out of
David> it. But tradition is tradition.
On Linux it's actually a published standard.
David> I also have persistant problems with auto-autoloads that
David> are "already loaded." I've commented on that but I'm
told
David> it's a "normal" bug.
This is _not_ normal. One possible cause is load-path shadows. M-x
list-load-path-shadows. Another possibility is a package that
contains a file that's also dumped into XEmacs. There may be others.
David> The package download system wants to put things in
David> /usr/local/lib/xemacs/pkgname
David> vice. /usr/local/lib/xemacs-packages/pkgname so I wind up
David> doing a manual step after each package update - serious
David> pita.
By "package download system" do you mean M-x list-packages or the
netinstaller?
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
2:06 p.m.
On 23 Mar 2002, Stephen J. Turnbull said:
You should need only one copy of the packages.
... saving things like incompatible byte-compiler changes (which
fortunately happen *very* rarely).
David> Personally, I'd just as soon move this up to
David> /usr/local/xemacs/xemacs-v.e.r and leave the /lib/ out of
David> it. But tradition is tradition.
On Linux it's actually a published standard.
As well as being the only halfway sane way to do this sort of thing. If
you want to organize by packages, use GNU stow and prefix= at install-
time.
(Or GNU stow and prefix= *and* exec_prefix= at install-time, as I do at
one of the more disk-space-starved sites at which I keep an XEmacs.)
David> I also have persistant problems with auto-autoloads
that
David> are "already loaded." I've commented on that but I'm
told
David> it's a "normal" bug.
This is _not_ normal. One possible cause is load-path shadows. M-x
list-load-path-shadows. Another possibility is a package that
contains a file that's also dumped into XEmacs. There may be others.
The one I normally see is that I organize my sitewide lisp into packages
with names similar to the XEmacs ones, and then the auto-autoloads file
generated by `batch-update-directory' gives the autoloads files feature
names the same as ones already used for non-site-specific XEmacs
packages.
(It's easily fixable by editing the auto-autoloads files by hand, and
because batch-update-directory edits the auto-autoloads files rather
than rewriting them, that only has to be done once...)
--
`Oh, I seeeee, good light; bad light. Presumably the bad light is
different -- perhaps it's a sawtooth waveform, and the pointy bits
scratch your eyes?' --- John Ineson to a `monitors emit radiation,
all radiation is bad, therefore monitors are bad' tub-thumper
4:28 p.m.
Stephen J. Turnbull wrote:
>>>>>"David" == David A Cobb
<superbiskit(a)cox.net> writes:
>>>>>
David> I have both i686-pc-cygwin and i586-pc-win32 versions and I
David> wish to have the *minimum* of duplication.
David> Especially, I do not want to have all the lisp plus the
David> packages in two places.
Sorry, the core Lisp has to go in two places. Different versions are
typically not API compatible internally. We moved everything we could
justify out to the packages, and there are persistent grumbles from
developers that X Y or Z "needs" to be in core.
Umm, is that "version" as in xemacs-21.5 /vs/ xemacs-21.4, or
xemacs-21.4.6/i586-pc-win32 /vs/ xemacs-21.4.6/i686-pc-cygwin ? I would
expect the former: my lisp is indeed under the release-specific
directory but is shared between the two targets.
You should need only one copy of the packages.
David> Personally, I'd just as soon move this up to
David> /usr/local/xemacs/xemacs-v.e.r and leave the /lib/ out of
David> it. But tradition is tradition.
On Linux it's actually a published standard.
Where? - just curious. It's only a minor quirk, but I don't see in what
sense xemacs is a library.
David> I also have persistant problems with auto-autoloads that
David> are "already loaded." I've commented on that but I'm
told
David> it's a "normal" bug.
This is _not_ normal. One possible cause is load-path shadows. M-x
list-load-path-shadows. Another possibility is a package that
contains a file that's also dumped into XEmacs. There may be others.
Aha! Consider the second possibility concerning dumping. How can I
determine what was dumped?
This consistantly happens once I've done a package update -- when I
first do the netinstall it is OK.
David> The package download system wants to put things in
David> /usr/local/lib/xemacs/pkgname
David> vice. /usr/local/lib/xemacs-packages/pkgname so I wind up
David> doing a manual step after each package update - serious
David> pita.
By "package download system" do you mean M-x list-packages or the
netinstaller?
(list-packages)
--
David A. Cobb, Software Engineer, Public Access Advocate
"By God's Grace I am a Christian man, by my actions a great sinner." -- The
Way of a Pilgrim; R. M. French, tr.
Life is too short to tolerate crappy software.
.
2:27 a.m.
>>>> "David" == David A Cobb
<superbiskit(a)cox.net> writes:
David> Umm, is that "version" as in xemacs-21.5 /vs/ xemacs-21.4,
Yes.
David> xemacs-21.4.6/i586-pc-win32 /vs/
David> xemacs-21.4.6/i686-pc-cygwin ? I would expect the former:
David> my lisp is indeed under the release-specific directory but
David> is shared between the two targets.
You can do that, as you infer. I believe this "just works" by
default, because the Lisp goes in the $prefix/lib/xemacs-$version/lisp
directory, while platform-specific executables go in $prefix/bin and
$prefix/lib/xemacs-$version/$arch.
I don't know if this works for Windows, because ISTR the native
Makefile varying from the *nix practice in a number of ways.
David> Where? - just curious. It's only a minor quirk, but I
David> don't see in what sense xemacs is a library.
It's called the Filesystem Hierarchy Standard (FHS). Most Linux
distros distribute it, so I don't know a canonical URL.
David> This consistantly happens once I've done a package update
David> -- when I first do the netinstall it is OK.
This is not dumped Lisp, then. What I have seen happen is that package
Lisp is placed in $prefix/xemacs/xemacs-packages/lisp/$package
according to policy, but the list-packages interface will put new ones
in $prefix/xemacs/lisp/$package for some reason. I haven't tracked
this down, it only seems to happen to some people.
The other possibility is that Mule packages are being placed into both
xemacs-packages and mule-packages. But up to now you probably haven't
been using Mule packages, right?
Either way, use M-x list-load-path-shadows to find them.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
9:08 p.m.
On Thu, 21 Mar 2002 15:51:53 +0900, "Stephen J. Turnbull" said:
>>>>> "Valdis" == Valdis Kletnieks
<Valdis.Kletnieks(a)vt.edu> writes:
Valdis> Whats wrong with this picture? (cut and pasted from output
Valdis> of 'make' with 'EMACSDEBUGPATHS=1'):
Nothing. This is the way Michael Sperber thinks it should be. There
was a thread on this a while back. The solutions are easy:
Hmm... I wonder why I didn't notice - probably because I wasn't paying attention
and hadn't gotten bit yet ;)
1. Add --package-path=/usr/local/lib/xemacs to your ./configure
args.
2. Install XEmacs in the normal way and run from there.
If either of those doesn't work, I definitely want to hear from you.
Based on your comment further down, I did this instead for testing:
EMACSPACKAGEPATH="/usr/local/lib/xemacs/mule-packages/:/usr/local/lib/xemacs/xemacs-packages/"
src/xemacs
Option (1) is a non-starter in my opinion - *everybody* is going to get
bit by this, because:
Option (2) is also a non-starter in general. If you have to jump through too many
hoops to test before saying 'make install', it won't happen.
(I'll add that once I managed to get 'src/xemacs' to come up, I *did* do
a 'make install' and things *do* work as expected after that).
Valdis> Is this a --pdump only issue? Does it work for
others?
No, and no. I'm not sure why the list is not full of enraged
people. :) At this point it should not be possible to run in-place
without an explicit spec (EMACSPACKAGEPATH at run time or
--package-path at build time) for the root of the packages hierarchy,
or a packages hierarchy rooted at the build root.
We're gonna have lots of enraged people when people who aren't running
the bleeding-edge CVS try this:
untar
./configure
make
src/xemacs
make install
(After all - don't we *all* at least try './newproggie' before we type
'make install' and overlay a known working copy? ;)
Michael argues (more or less) that XEmacs should have only one ROOT
such that the executable is $ROOT/bin/xemacs or $ROOT/src/xemacs, and
that the packages hierarchies should be rooted in $ROOT/*-packages for
run-in-place, or $ROOT/lib/xemacs/*-packages for an installed XEmacs.
This is the admin-centric view.
The people who get upset about the situation generally feel that the
version-specific root (ie, found relative to $ROOT/{bin,src}/xemacs)
is one thing, and the packages root something else. They feel that
since XEmacs knows where it will be installed (according to --prefix),
it should look there by default for the packages root. This is the
tester-centric view. :-)
Can somebody add this at the appropriate place in the code:
if (!package_path) {
printf("Warning no package path found. Try setting EMACSPACKAGEPATH\
if running-in-place");
}
or something similar? We may even want to output a "probably workable"
suggested
value intuited from the settings of --prefix and --mule....
/Valdis
5:06 a.m.
>>>> "Valdis" == Valdis Kletnieks
<Valdis.Kletnieks(a)vt.edu> writes:
Valdis> We may even want to output a "probably workable" suggested
Valdis> value intuited from the settings of --prefix and
Valdis> --mule....
What Michael is worried about is admins and binary kit builders
(remember binary kits? :( ) who want to make relocatable trees.
Martin was always big on this, too. It's a GoodThang[tm].
I think what he plans to do is to add the "probably workable value" as
a presumed root, and tell people who want relocatable trees to use
--with-prefix=no. That (already implemented) flag gets rid of the
built-in knowledge of default installation roots, so that Emacs is
forced to rely on paths relative to the executable.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
8088
days inactive
8093
days old
9 comments
5 participants
participants (5)
-
David A. Cobb -
Michael Sperber -
Nix -
Stephen J. Turnbull -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks