4:57 p.m.
I've just updated my workspace (yesterday) and rebuilt XEmacs. I
think that I'm using --with-prefix=no for the first time in a while (I
stupidly blew away my old Installation file), and I believe that is
related.
The symptoms are that Installation tells me that
Package Search (a 'root' contains '{xemacs,mule,site}-packages'):
User package roots: ~/.xemacs
System package roots: /usr/local/share/xemacs
and there are package hierarchies under both roots, but XEmacs starts
up with only the (single) package under ~/.xemacs and the core lisp
directories in load-path. Output of debug-paths appended. See
issue875 for beta.err containing Installation (actually, configure
output) and a build and check log.
I see two ways to go here. Mike used to argue that if XEmacs does not
build in knowledge of $prefix, the package root should be the same as
the installation root. In that case, since I'm running in place,
Installation is actually lying about where it will find the packages.
(And I bet it would get it wrong for an installed XEmacs unless it
were installed in /usr/local/{bin,etc,lib,share}, but --with-prefix=no
is precisely intended to make no such promises.) If that's the way
we're going to go, we need to fix Installation (ie, configure's
reporting function).
Personally I prefer to think of the packages as a quasi-independent
project, so the package installation has a root of its own. It would
be convenient if XEmacs respected its promise in Installation and
looked for packages there. But I suspect that would make things more
complicated for users who really want to install XEmacs and the
packages as a single self-contained bundle.
What does everybody think?
Steve
Starting program:
/Users/steve/src/XEmacs/21.5/pristine/+clang34/src/xemacs
--debug-paths
startup-setup-paths arguments:
inhibit-packages: nil
inhibit-site-lisp: nil
called-early: nil
invocation-directory:
"/Users/steve/src/XEmacs/21.5/pristine/+clang34/src/"
invocation-name: "xemacs"
configure-prefix-directory: nil
configure-exec-prefix-directory: nil
emacs-roots:
("/Users/steve/src/XEmacs/21.5/pristine/+clang34/"
"/Users/steve/src/XEmacs/21.5/pristine/")
emacs-data-roots:
("/Users/steve/src/XEmacs/21.5/pristine/+clang34/"
"/Users/steve/src/XEmacs/21.5/pristine/")
user-init-directory: "~/.xemacs/"
configure-package-path: nil
configure-lisp-directory and lisp-directory:
nil
"/Users/steve/src/XEmacs/21.5/pristine/+clang34/lisp/"
configure-mule-lisp-directory and mule-lisp-directory:
nil
"/Users/steve/src/XEmacs/21.5/pristine/+clang34/lisp/mule/"
configure-site-directory and site-directory:
nil
nil
configure-early-package-directories, early-package-hierarchies and
early-package-load-path:
nil
("~/.xemacs/xemacs-packages/")
("/Users/steve/.xemacs/xemacs-packages/lisp/"
"/Users/steve/.xemacs/xemacs-packages/lisp/vm/")
configure-late-package-directories, late-package-hierarchies and
late-package-load-path:
nil
nil
configure-last-package-directories, last-package-hierarchies and
last-package-load-path:
nil
nil
load-path:
("/Users/steve/.xemacs/xemacs-packages/lisp/"
"/Users/steve/.xemacs/xemacs-packages/lisp/vm/"
"/Users/steve/src/XEmacs/21.5/pristine/+clang34/lisp/mule/"
"/Users/steve/src/XEmacs/21.5/pristine/+clang34/lisp/")
configure-module-directory and module-directory:
nil
configure-site-module-directory and site-module-directory:
nil
nil
configure-info-directory, configure-info-path and Info-directory-list:
nil
nil
("/Users/steve/src/XEmacs/21.5/pristine/+clang34/info/"
"/opt/local/share/info/" "/Developer/usr/share/info/")
configure-exec-directory and exec-directory:
nil
"/Users/steve/src/XEmacs/21.5/pristine/+clang34/lib-src/"
exec-path:
("/opt/local/bin/" "/opt/local/sbin/" "/usr/bin/"
"/bin/" "/usr/sbin/"
"/sbin/" "/usr/local/bin/" "/opt/X11/bin/"
"/Users/steve/src/XEmacs/21.5/pristine/+clang34/lib-src/")
configure-doc-directory and doc-directory:
nil
"/Users/steve/src/XEmacs/21.5/pristine/+clang34/lib-src/"
configure-data-directory and data-directory:
nil
"/Users/steve/src/XEmacs/21.5/pristine/+clang34/etc/"
data-directory-list:
("/Users/steve/.xemacs/xemacs-packages/etc/"
"/Users/steve/.xemacs/xemacs-packages/etc/vm/"
"/Users/steve/src/XEmacs/21.5/pristine/+clang34/etc/")
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:56 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
I see two ways to go here. Mike used to argue that if XEmacs does
not
build in knowledge of $prefix, the package root should be the same as
the installation root. In that case, since I'm running in place,
Installation is actually lying about where it will find the packages.
(And I bet it would get it wrong for an installed XEmacs unless it
were installed in /usr/local/{bin,etc,lib,share}, but --with-prefix=no
is precisely intended to make no such promises.) If that's the way
we're going to go, we need to fix Installation (ie, configure's
reporting function).
Personally I prefer to think of the packages as a quasi-independent
project, so the package installation has a root of its own. It would
be convenient if XEmacs respected its promise in Installation and
looked for packages there. But I suspect that would make things more
complicated for users who really want to install XEmacs and the
packages as a single self-contained bundle.
What does everybody think?
There needs to be an option that, in the absence of other options
specifying explicit paths, means "no paths are compiled into the
binary". Currently, with-prefix is that option, and changing its
semantics would take this possibility away. (This option was not
created for running in place, but for creating relocatable binary
distributions.)
So I'm all in favor of changing Installation not to lie. It's easy
enough to tell configure to look for packages via the numerous
--with-XXX-packages options to configure.
--
Regards,
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:16 a.m.
Michael Sperber writes:
There needs to be an option that, in the absence of other options
specifying explicit paths, means "no paths are compiled into the
binary".
Er, how about "~/.xemacs"? That *does* work.
I guess I'd be more comfortable phrasing that as "XEmacs should have
an option that all search paths are computed relative to the running
instance (including environmental information like effective UID)". I
don't have a good compact phrase, maybe "no absolute paths" does the
trick?
Also, I'm not clear on this "absence of other options." What are the
semantics of "--with-prefix=no --with-system-packages=/usr/share/xemacs"?
Would it be possible/a good idea to make --with-prefix=no conflict
with options (including --with-*-packages) that specify search paths?
So I'm all in favor of changing Installation not to lie.
It's easy
enough to tell configure to look for packages via the numerous
--with-XXX-packages options to configure.
"Easy"? I can never remember the syntax. :-P It's certainly
"flexible" enough though! :-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:27 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
I guess I'd be more comfortable phrasing that as "XEmacs
should have
an option that all search paths are computed relative to the running
instance (including environmental information like effective UID)". I
don't have a good compact phrase, maybe "no absolute paths" does the
trick?
I'm totally amenable to that, but it's not what --with-prefix=no does -
that does exactly what it advertises, namely:
--with-prefix=no Don't compile the value for `prefix' into the
executable.
Also, I'm not clear on this "absence of other options."
What are the
semantics of "--with-prefix=no --with-system-packages=/usr/share/xemacs"?
Would it be possible/a good idea to make --with-prefix=no conflict
with options (including --with-*-packages) that specify search paths?
All other absolutely specified paths *will* get compiled in. And no, we
don't want it to conflict, because that would prevent you from doing
what you were trying to do do. (You should do --with-prefix=no
--with-late-packages=<...>, if I understand your goal correctly.)
> So I'm all in favor of changing Installation not to lie.
It's easy
> enough to tell configure to look for packages via the numerous
> --with-XXX-packages options to configure.
"Easy"? I can never remember the syntax. :-P It's certainly
"flexible" enough though! :-)
:-)
Hints on what kind of info make it easier are appreciated.
--
Regards,
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:15 p.m.
Michael Sperber writes:
I'm totally amenable to that, but it's not what
--with-prefix=no does -
that does exactly what it advertises, namely:
--with-prefix=no Don't compile the value for `prefix' into the
executable.
The whole thing is very confusing though. I think I do have it
straight, but "Don't compile the value for prefix", and "make a
relocatable package" are quite different.
I guess I'm not clear on what is meant by "relocatable" given that
"run-in-place" works with --with-prefix=yes.
All other absolutely specified paths *will* get compiled in. And no,
we
don't want it to conflict, because that would prevent you from doing
what you were trying to do do. (You should do --with-prefix=no
--with-late-packages=<...>, if I understand your goal correctly.)
> "Easy"? I can never remember the syntax. :-P
It's certainly
> "flexible" enough though! :-)
:-)
Hints on what kind of info make it easier are appreciated.
For starters, I think we should settle on a specific set of options
for configuring package paths, deprecate the rest ASAP, and get rid of
them in the next public release. I think probably the "early",
"late", "last" trio is easiest to understand the effects, and
"typically correspond to 'personal', 'system', and 'legacy'
=
'fallback' packages" as the explanation.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:23 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> I'm totally amenable to that, but it's not what --with-prefix=no does -
> that does exactly what it advertises, namely:
>
> --with-prefix=no Don't compile the value for `prefix' into the
> executable.
The whole thing is very confusing though. I think I do have it
straight, but "Don't compile the value for prefix", and "make a
relocatable package" are quite different.
That's right - here's the relationship: You can use "Don't compile the
value for prefix" to "make a relocatable package".
I guess I'm not clear on what is meant by "relocatable"
given that
"run-in-place" works with --with-prefix=yes.
Run-in-place is not the same "relocatable", and there's very specific
code to deal with this case.
For starters, I think we should settle on a specific set of options
for configuring package paths, deprecate the rest ASAP, and get rid of
them in the next public release. I think probably the "early",
"late", "last" trio is easiest to understand the effects, and
"typically correspond to 'personal', 'system', and 'legacy'
=
'fallback' packages" as the explanation.
Basically, I believe people should only ever configure "late", so my
recommendation would be to get rid of the "early" and "last" options
and
lose the "late". Acceptable?
--
Regards,
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4 p.m.
Michael Sperber writes:
> I guess I'm not clear on what is meant by
"relocatable" given that
> "run-in-place" works with --with-prefix=yes.
Run-in-place is not the same "relocatable", and there's very specific
code to deal with this case.
Sure, but what is the difference? If it can't be explained in words
of one syllable, maybe we should put --with-prefix into an "if you
don't know why you need this, you don't need it" section in the docs.
Basically, I believe people should only ever configure
"late", so my
recommendation would be to get rid of the "early" and "last" options
and
lose the "late". Acceptable?
So early is *always* user-init-directory? Do we know what that is
early enough for package initialization?
I guess we can lose the "last" option. In practice the system and
user roots should be enough for anybody. (Or is --with-last-packages
a search path rather than a single directory?) So this seems like a
reasonable simplification to me.
How about EMACSPACKAGEPATH? Same syntax and semantacs as
--with-*-packages? Does it replace or add to the built-in paths (if
any)?
(I know what the semantics are now, but if we do this it's going to be
the last chance to rethink these decisions for a while.)
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:10 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> > I guess I'm not clear on what is meant by "relocatable" given
that
> > "run-in-place" works with --with-prefix=yes.
>
> Run-in-place is not the same "relocatable", and there's very
specific
> code to deal with this case.
Sure, but what is the difference? If it can't be explained in words
of one syllable, maybe we should put --with-prefix into an "if you
don't know why you need this, you don't need it" section in the docs.
I'm confused by your confusion: Run-in-place has nothing to do with
"with-prefix", and I don't know why you ever thought so.
> Basically, I believe people should only ever configure
"late", so my
> recommendation would be to get rid of the "early" and "last"
options and
> lose the "late". Acceptable?
So early is *always* user-init-directory? Do we know what that is
early enough for package initialization?
Essentially, yes.
I guess we can lose the "last" option. In practice the
system and
user roots should be enough for anybody. (Or is --with-last-packages
a search path rather than a single directory?) So this seems like a
reasonable simplification to me.
This was originally meant for running the 21.1 in-tree packages with
21.2. (Or something like that.)
How about EMACSPACKAGEPATH? Same syntax and semantacs as
--with-*-packages?
No. Legacy. (I.e. before my time.) It combines all the package paths
into one. Do not use.
--
Regards,
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:16 p.m.
Michael Sperber writes:
I'm confused by your confusion: Run-in-place has nothing to do
with
"with-prefix", and I don't know why you ever thought so.
Both have to do with running an XEmacs that is not installed in a
fixed place. But the real question comes down to "should typical
users ever specify --with-prefix=no?" I guess.
> How about EMACSPACKAGEPATH? Same syntax and semantacs as
> --with-*-packages?
No. Legacy. (I.e. before my time.) It combines all the package paths
into one. Do not use.
But we need some way to tell a --with-prefix=no XEmacs where the
packages are at run time.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:42 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> I'm confused by your confusion: Run-in-place has nothing to do with
> "with-prefix", and I don't know why you ever thought so.
Both have to do with running an XEmacs that is not installed in a
fixed place. But the real question comes down to "should typical
users ever specify --with-prefix=no?" I guess.
Right. I suspect the answer is "no".
> > How about EMACSPACKAGEPATH? Same syntax and semantacs as
> > --with-*-packages?
>
> No. Legacy. (I.e. before my time.) It combines all the package paths
> into one. Do not use.
But we need some way to tell a --with-prefix=no XEmacs where the
packages are at run time.
OK. I'll put it on my list. (Which I *will* get to, but ... time ...)
--
Regards,
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:58 p.m.
Michael Sperber writes:
> Both have to do with running an XEmacs that is not installed in
a
> fixed place. But the real question comes down to "should typical
> users ever specify --with-prefix=no?" I guess.
Right. I suspect the answer is "no".
OK, let's document it that way (or maybe "If you don't know why you
need it, you don't need it.") I can do that (unless you really want
to:).
> But we need some way to tell a --with-prefix=no XEmacs where
the
> packages are at run time.
OK. I'll put it on my list. (Which I *will* get to, but ... time ...)
Yeah, me too.
Maybe it just comes down to picking a different enough name to avoid
confusion with the deprecated EMACSPACKAGEPATH? Or are you leaning
toward a command-line option?
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:04 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Maybe it just comes down to picking a different enough name to avoid
confusion with the deprecated EMACSPACKAGEPATH?
Yeah, that's already a hard problem :-)
XEMACS_PACKAGES
?
Or are you leaning toward a command-line option?
My general position is that environment variables should say something
about the environment rather than about a particular program's
configuration, so a command-line option would also be nice. (I
recognize that the more common use cases will need an environment
variable.)
--
Regards,
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:26 p.m.
Michael Sperber writes:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> Maybe it just comes down to picking a different enough name to avoid
> confusion with the deprecated EMACSPACKAGEPATH?
Yeah, that's already a hard problem :-)
XEMACS_PACKAGES
I was thinking XEMACSPACKAGEROOT. If I let you have *two*
underscores, and you pick one place and I pick the other, how about
that?
My general position is that environment variables should say
something about the environment rather than about a particular
program's configuration, so a command-line option would also be
nice. (I recognize that the more common use cases will need an
environment variable.)
OK, both is fine with me. We can drop the "xemacs-" prefix for the
command line option: "-package-root" is long (but not insanely so?)
Granted, "-packages" is shorter.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3491
days inactive
3494
days old
12 comments
2 participants
participants (2)
-
Michael Sperber -
Stephen J. Turnbull