bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 2818 bytes --]

The site-specific pieces of the initial load-path are different in the
nt/msysconfig.sh build from how they used to be with nt/configure.bat.

In src/epaths.h (when built), PATH_SITELOADSEARCH is defined as:

  with nt/configure.bat: "%emacs_dir%/site-lisp;%emacs_dir%/../site-lisp"

  with nt/msysconfig.sh:
"%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"

The former version was much more useful on Windows, allowing
one to keep a bunch of Emacs installs in a single parent directory
that also contains the site-lisp directory.

As a workaround I tried configuring with
"--enable-locallisppath=c:/emacs/site-lisp" but it didn't seem to have
any effect.

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-05-30 on 57172UHB
Bzr revision: 112785 xfq.free@gmail.com-20130530092755-xhnwfx1wk3ueebnk
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix c:/emacs/emacs-112785
 --enable-locallisppath=c:/emacs/site-lisp CPPFLAGS='-I G:/usr/include'
 LDFLAGS='-L G:/usr/lib''

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x f i n d - l i b <return> s i t e - s t a r t <return>
M-x r - e - b <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
find-library-name: Can't find library site-start

Load-path shadows:
None found.

Features:
(shadow sort nadvice gnus-util mail-extr emacsbug message format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils thingatpt find-func time-date
tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process w32notify w32 multi-tty emacs)

[-- Attachment #2: Type: text/html, Size: 3175 bytes --]

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> Date: Thu, 30 May 2013 14:46:13 +0100
> From: Richard Copley <rcopley@gmail.com>
> 
> The site-specific pieces of the initial load-path are different in the
> nt/msysconfig.sh build from how they used to be with nt/configure.bat.

Indeed, and that is on purpose.  I explained the rationale here:

  http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00146.html

> In src/epaths.h (when built), PATH_SITELOADSEARCH is defined as:
> 
>   with nt/configure.bat: "%emacs_dir%/site-lisp;%emacs_dir%/../site-lisp"
> 
>   with nt/msysconfig.sh:
> "%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"
> 
> The former version was much more useful on Windows, allowing
> one to keep a bunch of Emacs installs in a single parent directory
> that also contains the site-lisp directory.

Sorry, I don't follow.  Please describe what structure was possible
beforehand that you think is impossible now.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]

On 30 May 2013 17:40, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Thu, 30 May 2013 14:46:13 +0100
> > From: Richard Copley <rcopley@gmail.com>
> >
> > The site-specific pieces of the initial load-path are different in the
> > nt/msysconfig.sh build from how they used to be with nt/configure.bat.
>
> Indeed, and that is on purpose.  I explained the rationale here:
>
>   http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00146.html
>
> > In src/epaths.h (when built), PATH_SITELOADSEARCH is defined as:
> >
> >   with nt/configure.bat: "%emacs_dir%/site-lisp;%emacs_dir%/../site-lisp"
> >
> >   with nt/msysconfig.sh:
> >
> "%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"
> >
> > The former version was much more useful on Windows, allowing
> > one to keep a bunch of Emacs installs in a single parent directory
> > that also contains the site-lisp directory.
>
> Sorry, I don't follow.  Please describe what structure was possible
> beforehand that you think is impossible now.
>

I'm not sure which part you're having trouble with, so I'll be quite
expansive and hopefully you'll see what I mean. Perhaps this should be
a reply to the emacs-devel message, but I didn't see that at the time
and it's a bit late now.

What used sometimes to be called NT Emacs is (or was) a portable app.
When you've unpacked (or built) it, everything is inside "bin/..".
Call that the "application directory". You install by moving and
renaming the application directory, and uninstall by deleting.
Ideally, you never modify any file inside the application directory.
Putting an Emacs bin directory on the system-wide path is optional.
The user can be trusted to work out how to invoke the right executable.
Emacs finds the right auxiliary executables and DOC file just fine,
even with the "-Q" command-line argument.

I had a bunch of these application directories, my own builds of the
trunk, at different revisions. Like this (but with more Emacs):

  c:\>dir /B c:\emacs
  emacs-111818
  emacs-112125
  emacs-112416
  site-lisp

This particular arrangement was suggested, to my mind anyway, by
the existence of the "%emacs_dir%/../site-lisp" entry in load-path.

I don't say it's impossible to do the same thing any more, just that
it no longer works out of the box as it used to (unless of course I've
made some other mistake). If, as you say, it's a design decision, then
that's fine. I disagree but I don't object.

[-- Attachment #2: Type: text/html, Size: 3287 bytes --]

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> Date: Thu, 30 May 2013 18:56:10 +0100
> From: Richard Copley <rcopley@gmail.com>
> Cc: 14513@debbugs.gnu.org
> 
> What used sometimes to be called NT Emacs is (or was) a portable app.
> When you've unpacked (or built) it, everything is inside "bin/..".
> Call that the "application directory". You install by moving and
> renaming the application directory, and uninstall by deleting.
> Ideally, you never modify any file inside the application directory.
> Putting an Emacs bin directory on the system-wide path is optional.
> The user can be trusted to work out how to invoke the right executable.
> Emacs finds the right auxiliary executables and DOC file just fine,
> even with the "-Q" command-line argument.

This is all still true, except that some of the directories are not
immediately below the root of the installation tree, but somewhat
deeper.  E.g., what was previously in ROOT/lisp is now in
ROOT/share/emacs/VERSION/lisp.  Why is that difference important?

> I had a bunch of these application directories, my own builds of the
> trunk, at different revisions. Like this (but with more Emacs):
> 
>   c:\>dir /B c:\emacs
>   emacs-111818
>   emacs-112125
>   emacs-112416
>   site-lisp

You can still have separate directories like that, unless I'm missing
something.  The directory structure below emacs-NNNNNN directories
will be different, but that's all.

> This particular arrangement was suggested, to my mind anyway, by
> the existence of the "%emacs_dir%/../site-lisp" entry in load-path.

Did you really have files in "%emacs_dir%/../site-lisp"?  If you did,
you'd probably be the first one I know about who did.  Most people
don't even know that directory is looked in.

If you do have files in this directory, you'll have to copy them into
each new tree, if you really want the threes to be separate, not under
a single root.  But you'll probably need that anyway, because Lisp
files had better be compiled by the Emacs version that runs them.

> I don't say it's impossible to do the same thing any more, just that
> it no longer works out of the box as it used to

What exactly doesn't work?  Uninstalling by removing a single tree?
Or something else?

If that's uninstalling, and you don't want or cannot "make uninstall",
it should be easy to create a simple script that, given a root
directory and a version, will delete the subdirectories that belong to
that version only.  There aren't too many directories to delete,
basically libexec/emacs/VERSION and share/emacs/VERSION.  That, and
the emacs-VERSION*.exe executables in bin/.

Did I miss something?

> If, as you say, it's a design decision, then that's fine. I disagree
> but I don't object.

The new structure has advantages which I described in that mail in
March.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Achim Gratz]

Eli Zaretskii writes:
> This is all still true, except that some of the directories are not
> immediately below the root of the installation tree, but somewhat
> deeper.  E.g., what was previously in ROOT/lisp is now in
> ROOT/share/emacs/VERSION/lisp.  Why is that difference important?

It is not, the OP's talking about the missing "../site-lisp" part.

> Did you really have files in "%emacs_dir%/../site-lisp"?  If you did,
> you'd probably be the first one I know about who did.  Most people
> don't even know that directory is looked in.

FWIW, I use a directory structure which relies on a ../site-lisp to be
accessible by multiple Emacs versions installed in parallel, just like
on UN*Xy boxes.

> If you do have files in this directory, you'll have to copy them into
> each new tree, if you really want the threes to be separate, not under
> a single root.  But you'll probably need that anyway, because Lisp
> files had better be compiled by the Emacs version that runs them.

When was that change announced?  It used to be sufficient to compile
them with the oldest Emacs version (or not at all).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Thu, 30 May 2013 21:02:54 +0200
> 
> Eli Zaretskii writes:
> > This is all still true, except that some of the directories are not
> > immediately below the root of the installation tree, but somewhat
> > deeper.  E.g., what was previously in ROOT/lisp is now in
> > ROOT/share/emacs/VERSION/lisp.  Why is that difference important?
> 
> It is not, the OP's talking about the missing "../site-lisp" part.

It's not missing, it's in ROOT/share/emacs/site-lisp now.

> > Did you really have files in "%emacs_dir%/../site-lisp"?  If you did,
> > you'd probably be the first one I know about who did.  Most people
> > don't even know that directory is looked in.
> 
> FWIW, I use a directory structure which relies on a ../site-lisp to be
> accessible by multiple Emacs versions installed in parallel, just like
> on UN*Xy boxes.

Unix boxes use exactly the directory structure that is now encoded in
epaths.h.  So we got closer to Unix, not farther.

> > If you do have files in this directory, you'll have to copy them into
> > each new tree, if you really want the threes to be separate, not under
> > a single root.  But you'll probably need that anyway, because Lisp
> > files had better be compiled by the Emacs version that runs them.
> 
> When was that change announced?  It used to be sufficient to compile
> them with the oldest Emacs version (or not at all).

I said "probably" and "had better".  My gray hair taught me not to
trust old *.elc files, especially since site-lisp is home to all kind
of 3rd party packages that aren't as disciplined as the bundled ones.
YMMV.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Achim Gratz]

Eli Zaretskii writes:
>> FWIW, I use a directory structure which relies on a ../site-lisp to be
>> accessible by multiple Emacs versions installed in parallel, just like
>> on UN*Xy boxes.
>
> Unix boxes use exactly the directory structure that is now encoded in
> epaths.h.  So we got closer to Unix, not farther.

On UN*X the installation of several versions is usually done into the
same $prefix, but you don't normally do that on Windows where each
install is usually unpacked into its own tree.  This means that when
it's time to remove an old version tree you'd need to remember that
site-lisp must be rescued or you need to start installing your Windows
Emacsen into the same $prefix just like on UN*X.  Which is a bit
annoying when you want to keep some versions around from before that
change or your system administrator can't be convinced to change how the
installation is done.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Thu, 30 May 2013 21:57:02 +0200
> 
> Eli Zaretskii writes:
> >> FWIW, I use a directory structure which relies on a ../site-lisp to be
> >> accessible by multiple Emacs versions installed in parallel, just like
> >> on UN*Xy boxes.
> >
> > Unix boxes use exactly the directory structure that is now encoded in
> > epaths.h.  So we got closer to Unix, not farther.
> 
> On UN*X the installation of several versions is usually done into the
> same $prefix, but you don't normally do that on Windows where each
> install is usually unpacked into its own tree.

It was, until now.  From now on, they will all easily unpack into the
same tree, because the top-level directory in the zip file won't be
emacs-XX.YY anymore.

> This means that when it's time to remove an old version tree you'd
> need to remember that site-lisp must be rescued or you need to start
> installing your Windows Emacsen into the same $prefix just like on
> UN*X.  Which is a bit annoying when you want to keep some versions
> around from before that change or your system administrator can't be
> convinced to change how the installation is done.

Well, then just don't do that.  Don't unpack each version into a
separate directory.  That's what this change was all about.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Stefan Monnier]

> Well, then just don't do that.  Don't unpack each version into a
> separate directory.  That's what this change was all about.

There are good reasons to use a different root for each version.
Mostly, that lets you uninstall a given version with a simple "delete
directory".

On Unix systems, this is usually solved with some kind of package
manager, but if/when I install packages by hand, I usually install them
into a separate directory (via "--prefix=/foo/bar/<package>-<version>"),
and then add a few symlinks from a central location as needed.


        Stefan

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Achim Gratz]

Eli Zaretskii writes:
> Well, then just don't do that.  Don't unpack each version into a
> separate directory.  That's what this change was all about.

I have no dogs in this race.  On the two Windows systems that I care
about I have full administrative priviledges and can install (and
re-install) things exactly the way I want them.  I'll reiterate that
(just as on UN*X) many users are at the mercy of whoever administrates
their system and such changes often take a long time to trickle through
to these people (they may not understand what Emacs is, much less care
about site-lisp).  If this is at least documented clearly (not just that
this change is made, but _how_ to install things differently now) then
some churn can perhaps be avoided by having something to point to.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Fri, 31 May 2013 21:01:32 +0200
> 
> If this is at least documented clearly

I added a description of the new tree to etc/NEWS.

> (not just that this change is made, but _how_ to install things
> differently now)

Not sure what this means.  Please take a look at the text I wrote, and
if you have further suggestions, please speak up.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Stefan Monnier]

> This is all still true, except that some of the directories are not
> immediately below the root of the installation tree, but somewhat
> deeper.  E.g., what was previously in ROOT/lisp is now in
> ROOT/share/emacs/VERSION/lisp.  Why is that difference important?

He's not complaining about that.  He's annoyed about having removed
%emacs_dir%/../site-lisp from the load-path.

>> c:\>dir /B c:\emacs
>> emacs-111818
>> emacs-112125
>> emacs-112416
>> site-lisp

> You can still have separate directories like that, unless I'm missing
> something.

Except that the site-lisp file now won't be used any more unless you ask
for it manually in your .emacs.

> Did you really have files in "%emacs_dir%/../site-lisp"?

Apparently he did, yes.

> If you do have files in this directory, you'll have to copy them into
> each new tree, if you really want the threes to be separate, not under
> a single root.

No: he specifically wants to share all the external packages under
a single site-lisp.

> But you'll probably need that anyway, because Lisp
> files had better be compiled by the Emacs version that runs them.

No, they work just fine as long as the compiler was older than the runner.


        Stefan

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Richard Copley <rcopley@gmail.com>,  14513@debbugs.gnu.org
> Date: Thu, 30 May 2013 15:06:26 -0400
> 
> He's not complaining about that.  He's annoyed about having removed
> %emacs_dir%/../site-lisp from the load-path.
> 
> >> c:\>dir /B c:\emacs
> >> emacs-111818
> >> emacs-112125
> >> emacs-112416
> >> site-lisp
> 
> > You can still have separate directories like that, unless I'm missing
> > something.
> 
> Except that the site-lisp file now won't be used any more unless you ask
> for it manually in your .emacs.

No, he should just move the contents into ROOT/share/emacs/site-lisp.

> > But you'll probably need that anyway, because Lisp
> > files had better be compiled by the Emacs version that runs them.
> 
> No, they work just fine as long as the compiler was older than the runner.

In theory, yes.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 3769 bytes --]

On 30 May 2013 19:20, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Thu, 30 May 2013 18:56:10 +0100
> > From: Richard Copley <rcopley@gmail.com>
> > Cc: 14513@debbugs.gnu.org
> >
> > What used sometimes to be called NT Emacs is (or was) a portable app.
> > When you've unpacked (or built) it, everything is inside "bin/..".
> > Call that the "application directory". You install by moving and
> > renaming the application directory, and uninstall by deleting.
> > Ideally, you never modify any file inside the application directory.
> > Putting an Emacs bin directory on the system-wide path is optional.
> > The user can be trusted to work out how to invoke the right executable.
> > Emacs finds the right auxiliary executables and DOC file just fine,
> > even with the "-Q" command-line argument.
>
> This is all still true,


Oh no it isn't.

except that some of the directories are not
> immediately below the root of the installation tree, but somewhat
> deeper.  E.g., what was previously in ROOT/lisp is now in
> ROOT/share/emacs/VERSION/lisp.  Why is that difference important?
>

That difference is not important.

 > I had a bunch of these application directories, my own builds of the
> > trunk, at different revisions. Like this (but with more Emacs):
> >
> >   c:\>dir /B c:\emacs
> >   emacs-111818
> >   emacs-112125
> >   emacs-112416
> >   site-lisp
>
> You can still have separate directories like that, unless I'm missing
> something.  The directory structure below emacs-NNNNNN directories
> will be different, but that's all.
>

Also the site-lisp directory will not be on the load-path.


>  > This particular arrangement was suggested, to my mind anyway, by
> > the existence of the "%emacs_dir%/../site-lisp" entry in load-path.
>
> Did you really have files in "%emacs_dir%/../site-lisp"?


Yes, that site-lisp directory up there is where my site lisp files are,
really.


> If you did,
> you'd probably be the first one I know about who did.  Most people
> don't even know that directory is looked in.
>

If you say so. I'm the freak who looked at load-path. :P

If you do have files in this directory, you'll have to copy them into
> each new tree, if you really want the threes to be separate, not under
> a single root.


That seems like a disadvantage.


>  But you'll probably need that anyway, because Lisp
> files had better be compiled by the Emacs version that runs them.
>

That's a fair point. I've never had a problem but it would be easy enough
to recompile as necessary. I'm not actively using more than one build.

> I don't say it's impossible to do the same thing any more, just that
> > it no longer works out of the box as it used to
>
> What exactly doesn't work?  Uninstalling by removing a single tree?
> Or something else?
>

The site-lisp directory is not searched.


> If that's uninstalling, and you don't want or cannot "make uninstall".


It's funny how differently we work! I can't make uninstall because
I kept the installation directory and discarded the build directory.


> it should be easy to create a simple script that, given a root
> directory and a version, will delete the subdirectories that belong to
> that version only.  There aren't too many directories to delete,
> basically libexec/emacs/VERSION and share/emacs/VERSION.  That, and
> the emacs-VERSION*.exe executables in bin/.
>
> Did I miss something?
>

With the uninstallation? No idea. It's ok, there's no way I'll be doing
that.


>  > If, as you say, it's a design decision, then that's fine. I disagree
> > but I don't object.
>
> The new structure has advantages which I described in that mail in
> March.
>

(1) You're the first one I know about who thinks that's important.
(2) is wrong.
(3) I don't follow. Other platforms, really?

[-- Attachment #2: Type: text/html, Size: 6631 bytes --]

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> Date: Thu, 30 May 2013 20:14:35 +0100
> From: Richard Copley <rcopley@gmail.com>
> 
> > >   c:\>dir /B c:\emacs
> > >   emacs-111818
> > >   emacs-112125
> > >   emacs-112416
> > >   site-lisp
> >
> > You can still have separate directories like that, unless I'm missing
> > something.  The directory structure below emacs-NNNNNN directories
> > will be different, but that's all.
> >
> 
> Also the site-lisp directory will not be on the load-path.

Your site-lisp won't, but the one in ROOT/share/emacs will.

> I'm not actively using more than one build.

Then why do you need separate trees?  That's the only reason why you
need the site-lisp outside of the Emacs tree.  Use the Posix-standard
structure and one root for all the Emacs installations, and the
problem is gone, because you have the common site-lisp directory in
ROOT/share/emacs.

> > it should be easy to create a simple script that, given a root
> > directory and a version, will delete the subdirectories that belong to
> > that version only.  There aren't too many directories to delete,
> > basically libexec/emacs/VERSION and share/emacs/VERSION.  That, and
> > the emacs-VERSION*.exe executables in bin/.
> >
> > Did I miss something?
> >
> 
> With the uninstallation? No idea. It's ok, there's no way I'll be doing
> that.

You mean, you will never uninstall?  Then why do you keep the versions
separate?

> > The new structure has advantages which I described in that mail in
> > March.
> 
> (1) You're the first one I know about who thinks that's important.

Well, maybe I'm the only one who works on so many platforms.

> (2) is wrong.

It's not wrong as long as you keep all the installations under the
same root, like /usr/local on Unix.

> (3) I don't follow. Other platforms, really?

Yes.  Imagine that your --prefix is on a networked volume that can be
accessed from Windows and Unix systems alike.  Then only the
architecture-dependent files (binaries) need to be separate;
everything under %emacs_dir%/share/emacs/ can be installed only once
and used by Emacs from any OS.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Stefan Monnier]

Regardless of the details, I think for simple reasons of backward
compatibility, I think Richard's request to re-add
%emacs_dir%/../site-lisp makes sense (and such a site-lisp external to
the ROOT probably also makes sense for the NS build).

How hard would it be to add it?


        Stefan

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Richard Copley <rcopley@gmail.com>,  14513@debbugs.gnu.org
> Date: Thu, 30 May 2013 16:00:07 -0400
> 
> Regardless of the details, I think for simple reasons of backward
> compatibility, I think Richard's request to re-add
> %emacs_dir%/../site-lisp makes sense (and such a site-lisp external to
> the ROOT probably also makes sense for the NS build).
> 
> How hard would it be to add it?

Hard has nothing to do with this.  It will be against the principle of
having the tree structures on Unix and Windows the same.  Adapting to
this change is very simple.  So I see no reason to make such a change.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Stefan Monnier]

> Hard has nothing to do with this.  It will be against the principle of
> having the tree structures on Unix and Windows the same.

I wouldn't be opposed to making such a change on the Unix side as well,
although admittedly $prefix/../site-list doesn't sound like a good idea
when $prefix is /usr/local or /usr.

> Adapting to this change is very simple.

We should advertise it (I presume you mean the use
of --enable-locallisppath=PATH) at least as loudly as the "default
$prefix is probably not good for you".


        Stefan

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rcopley@gmail.com,  14513@debbugs.gnu.org
> Date: Thu, 30 May 2013 17:43:02 -0400
> 
> > Hard has nothing to do with this.  It will be against the principle of
> > having the tree structures on Unix and Windows the same.
> 
> I wouldn't be opposed to making such a change on the Unix side as well,

Then I will have no objections.

> although admittedly $prefix/../site-list doesn't sound like a good idea
> when $prefix is /usr/local or /usr.

Indeed.

> > Adapting to this change is very simple.
> 
> We should advertise it (I presume you mean the use
> of --enable-locallisppath=PATH) at least as loudly as the "default
> $prefix is probably not good for you".

I'd prefer to poll users whether they use that ../site-lisp directory,
before adding this to the instructions.  I suspect very few do, which
would mean we make the instructions more complex than they already
are.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

On 31 May 2013 07:20, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Stefan Monnier <monnier@iro.umontreal.ca>

> > Adapting to this change is very simple.
> >
> > We should advertise it (I presume you mean the use
> > of --enable-locallisppath=PATH) at least as loudly as the "default
> > $prefix is probably not good for you".
>
>
Just a reminder that --enable-locallisppath=PATH seems not to work
(I mentioned that in my original post). Also I'm not sure how you would
use it to add "ROOT/../site-lisp", which is what you would need for
backward compatibility.

>
> I'd prefer to poll users whether they use that ../site-lisp directory,
> before adding this to the instructions.  I suspect very few do, which
> would mean we make the instructions more complex than they already
> are.
>
>
FWIW I asked my two Emacs-using co-workers. One uses ROOT\..\site-lisp
(but doesn't have strong feelings either way), the other has no user- or
site-
lisp files at all.

[-- Attachment #2: Type: text/html, Size: 1776 bytes --]

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> Date: Fri, 31 May 2013 10:52:11 +0100
> From: Richard Copley <rcopley@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 14513@debbugs.gnu.org
> 
> > > We should advertise it (I presume you mean the use
> > > of --enable-locallisppath=PATH) at least as loudly as the "default
> > > $prefix is probably not good for you".
> >
> >
> Just a reminder that --enable-locallisppath=PATH seems not to work
> (I mentioned that in my original post).

Patches are welcome to support it.  You need to add something to
editing of epaths.nt in the epaths-force-w32 rule.

> Also I'm not sure how you would use it to add "ROOT/../site-lisp",
> which is what you would need for backward compatibility.

ROOT is %emacs_dir%, or maybe I don't understand what you are saying.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On 31 May 2013 12:35, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Fri, 31 May 2013 10:52:11 +0100
> > From: Richard Copley <rcopley@gmail.com>
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 14513@debbugs.gnu.org
> >
> > > > We should advertise it (I presume you mean the use
> > > > of --enable-locallisppath=PATH) at least as loudly as the "default
> > > > $prefix is probably not good for you".
> > >
> > >
> > Just a reminder that --enable-locallisppath=PATH seems not to work
> > (I mentioned that in my original post).
>
> Patches are welcome to support it.  You need to add something to
> editing of epaths.nt in the epaths-force-w32 rule.
>

I will have a go.


> > Also I'm not sure how you would use it to add "ROOT/../site-lisp",
> > which is what you would need for backward compatibility.
>
> ROOT is %emacs_dir%, or maybe I don't understand what you are saying.
>

So you would use "--enable-locallisppath=%emacs_dir%/../site-lisp".
Okay, I suppose that is fairly obvious. Thanks.

[-- Attachment #2: Type: text/html, Size: 1888 bytes --]

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Richard Copley]

[-- Attachment #1.1: Type: text/plain, Size: 1653 bytes --]

On 31 May 2013 13:55, Richard Copley <rcopley@gmail.com> wrote:
> On 31 May 2013 12:35, Eli Zaretskii <eliz@gnu.org> wrote:
> > > Date: Fri, 31 May 2013 10:52:11 +0100
> > > From: Richard Copley <rcopley@gmail.com>
> > > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 14513@debbugs.gnu.org
> > >
> > > > > We should advertise it (I presume you mean the use
> > > > > of --enable-locallisppath=PATH) at least as loudly as the "default
> > > > > $prefix is probably not good for you".
> > > >
> > > >
> > > Just a reminder that --enable-locallisppath=PATH seems not to work
> > > (I mentioned that in my original post).
> > Patches are welcome to support it.  You need to add something to
> > editing of epaths.nt in the epaths-force-w32 rule.
> I will have a go.

See attached. Here is a brief description:

Support the --enable-locallisppath argument on Windows, by making use
of the value of ${locallisppath} supplied by `configure'.
Also correct the description of ${locallisppath} in epaths.in and epaths.nt.

I don't know about Changelogs and stuff. Is there any chance
I can leave all that up to the real developers please?

Tested with kit as in INSTALL.MSYS, including Make 3.82.90,
and gives the expected results in epaths.h:

msysconfig.sh
=> #define PATH_SITELOADSEARCH
"%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"

msysconfig.sh "--prefix=/c/Program Files (x86)/GNU Emacs/emacs-112416"
=> #define PATH_SITELOADSEARCH
"%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"

msysconfig.sh --locallisppath=%emacs_dir%/../site-lisp
=> #define PATH_SITELOADSEARCH "%emacs_dir%/../site-lisp"

[-- Attachment #1.2: Type: text/html, Size: 2360 bytes --]

[-- Attachment #2: msys-locallisppath.patch --]
[-- Type: application/octet-stream, Size: 3116 bytes --]

=== modified file 'Makefile.in'
--- Makefile.in	2013-05-16 09:58:56 +0000
+++ Makefile.in	2013-06-01 15:33:44 +0000
@@ -321,11 +321,25 @@
 # Convert MSYS-style /x/foo file name into x:/foo that Windows can grok.
 msys_to_w32=sed -e 's,^/\([A-Za-z]\)/,\1:/,'
 
+# Fix up MSYS directory search path for Windows. Remove empty components,
+# convert each component as by msys_to_w32 above, and change the separator.
+# Replace ${prefix} with %emacs_dir% (env var expanded by Emacs at init time).
+# This is so we can make use of the value of ${locallisppath} supplied by
+# configure, to support the --enable-locallisppath argument.
+msys_sed_sh_escape=sed -e 's/[]\;$$*.^[]/\\\\&/g'
+msys_lisppath_to_w32=sed -e 's/:\+/:/g' -e 's/^://g' -e 's/:$$//g'	  \
+			 -e 's;\(^\|:\)'"$${prefixpattern}"'\([:/]\|$$\);\1%emacs_dir%\2;g'	  \
+			 -e 's/:/\\\\;/g'				  \
+			 -e 's,\(^\|;\)/\([A-Za-z]\)/,\1\2:/,g'
+
 # The w32 build needs a slightly different editing, and it uses
 # nt/epaths.nt as the template.
 epaths-force-w32: FRC
 	@(w32srcdir=`echo "${srcdir}" | ${msys_to_w32}` ; 	\
+	  prefixpattern=`echo '${prefix}' | ${msys_sed_sh_escape}` ; \
+	  locallisppath=`echo '${locallisppath}' | ${msys_lisppath_to_w32}` ; \
 	  sed < ${srcdir}/nt/epaths.nt > epaths.h.$$$$		\
+	  -e 's;\(#.*PATH_SITELOADSEARCH\).*$$;\1 "'"$${locallisppath}"'";' \
 	  -e '/^.*#/s/@VER@/${version}/g' 			\
 	  -e '/^.*#/s/@CFG@/${configuration}/g' 		\
 	  -e "/^.*#/s|@SRC@|$${w32srcdir}|g") &&		\

=== modified file 'nt/epaths.nt'
--- nt/epaths.nt	2013-04-06 13:25:17 +0000
+++ nt/epaths.nt	2013-06-01 15:27:46 +0000
@@ -41,10 +41,10 @@
 #define PATH_LOADSEARCH "%emacs_dir%/share/emacs/@VER@/lisp;%emacs_dir%/share/emacs/@VER@/leim"
 
 /* Like PATH_LOADSEARCH, but contains the non-standard pieces.
-   These are the site-lisp directories, typically something like
+   These are the site-lisp directories. Configure sets this to
+   ${locallisppath}, which typically defaults to something like:
    <datadir>/emacs/VERSION/site-lisp:<datadir>/emacs/site-lisp
-   Configure prepends any $locallisppath, as set by the
-   --enable-locallisppath argument.
+   but can be overridden by the --enable-locallisppath argument.
    This is combined with PATH_LOADSEARCH to make the default load-path.
    If the --no-site-lisp option is used, this piece is excluded.
 */

=== modified file 'src/epaths.in'
--- src/epaths.in	2013-01-01 09:11:05 +0000
+++ src/epaths.in	2013-05-31 22:11:31 +0000
@@ -30,10 +30,10 @@
 
 
 /* Like PATH_LOADSEARCH, but contains the non-standard pieces.
-   These are the site-lisp directories, typically something like
+   These are the site-lisp directories. Configure sets this to
+   ${locallisppath}, which typically defaults to something like:
    <datadir>/emacs/VERSION/site-lisp:<datadir>/emacs/site-lisp
-   Configure prepends any $locallisppath, as set by the
-   --enable-locallisppath argument.
+   but can be overridden by the --enable-locallisppath argument.
    This is combined with PATH_LOADSEARCH to make the default load-path.
    If the --no-site-lisp option is used, this piece is excluded.
 */

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> Date: Sat, 1 Jun 2013 17:04:11 +0100
> From: Richard Copley <rcopley@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 14513@debbugs.gnu.org
> 
> See attached.

Thanks.

> I don't know about Changelogs and stuff. Is there any chance
> I can leave all that up to the real developers please?

That's OK.

> Tested with kit as in INSTALL.MSYS, including Make 3.82.90,
> and gives the expected results in epaths.h:
> 
> msysconfig.sh
> => #define PATH_SITELOADSEARCH
> "%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"
> 
> msysconfig.sh "--prefix=/c/Program Files (x86)/GNU Emacs/emacs-112416"
> => #define PATH_SITELOADSEARCH
> "%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"
> 
> msysconfig.sh --locallisppath=%emacs_dir%/../site-lisp
> => #define PATH_SITELOADSEARCH "%emacs_dir%/../site-lisp"

Does it support Windows style paths and the ';' separator, as in

  --locallisppath='%emacs_dir%/../site-lisp;d:/wherever/site-lisp'

?  MSYS supports both Windows style file names and Windows style in
--prefix, so I'd like to support both styles in --locallisppath.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

On 1 June 2013 17:38, Eli Zaretskii <eliz@gnu.org> wrote:

> Does it support Windows style paths and the ';' separator, as in
>
>   --locallisppath='%emacs_dir%/../site-lisp;d:/wherever/site-lisp'
>
> ?  MSYS supports both Windows style file names and Windows style in
> --prefix, so I'd like to support both styles in --locallisppath.
>

It does not, I'm afraid. I'll try and fix that, and send a replacement
patch.

[-- Attachment #2: Type: text/html, Size: 779 bytes --]

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]

[Sorry, I dropped the list from the CC again.]

On 1 June 2013 18:29, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sat, 1 Jun 2013 18:25:14 +0100
> > From: Richard Copley <rcopley@gmail.com>
> >
> > No I won't, sorry. I'd forgotten: that's not possible without resorting
> to
> > heuristics, because ${locallisppath} is potentially a ":"-separated path.
>
> Is it possible to support only the Windows style?  That's the least we
> can do, because the result _must_ be a Windows-style path, or else it
> won't work, since Emacs is a native Windows executable.
>

That might be more logical than supporting only MSYS style.
But note the result is a Windows-style path with the above patch, e.g.
    "--enable-locallisppath=/c/emacs/site-lisp"
gives
    #define PATH_SITELOADSEARCH "c:/emacs/site-lisp"

On 1 June 2013 18:38, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sat, 1 Jun 2013 18:25:14 +0100
> > From: Richard Copley <rcopley@gmail.com>
> >
> > > It does not, I'm afraid. I'll try and fix that, and send a replacement
> > > patch.
> > >
> >
> > No I won't, sorry. I'd forgotten: that's not possible without resorting
> to
> > heuristics, because ${locallisppath} is potentially a ":"-separated path.
>
> Btw, you need not resort to heuristics even if you don't know whether
> ${locallisppath} is MSYS style or Windows style.  You can rely on the
> fact that MSYS transforms the path when it calls a native Windows
> application.  Here's an example, using cpp.exe, which is an
> application you can rely on being available and on being a MinGW
> executable:
>
>   $ cpp -dM -Dfoo=/d/usr/bin:/c/windows < /dev/null | fgrep foo
>   #define foo d:\usr\bin;c:\windows
>   $ cpp -dM -Dfoo='d:/usr/bin;c:/windows' < /dev/null | fgrep foo
>   #define foo d:/usr/bin;c:/windows
>
> (You'd need to convert backslashes to forward slashes in the first
> example, but that's easy, right?)
>
> The only requirement is that the argument to --locallisppath uses one
> of the two styles consistently.  But that is a reasonable requirement,
> I think.
>

Interesting, thanks.
I might have another patch later.

[-- Attachment #2: Type: text/html, Size: 3311 bytes --]

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Richard Copley]

[-- Attachment #1.1: Type: text/plain, Size: 1685 bytes --]

On 1 June 2013 17:38, Eli Zaretskii <eliz@gnu.org> wrote:

> Does it support Windows style paths and the ';' separator, as in
>
>   --locallisppath='%emacs_dir%/../site-lisp;d:/wherever/site-lisp'
>
> ?  MSYS supports both Windows style file names and Windows style in
> --prefix, so I'd like to support both styles in --locallisppath.
>

> Date: Sat, 1 Jun 2013 18:25:14 +0100
> From: Richard Copley <rcopley@gmail.com>
> [...] that's not possible without resorting to
> heuristics, because ${locallisppath} is potentially a ":"-separated path.

The attached patch supports both styles. The heuristics didn't turn
out to be as hairy as I imagined.

A few test cases:

nt/msysconfig.sh
#define PATH_SITELOADSEARCH
"%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"

nt/msysconfig.sh --prefix c:/emacs/emacs-112809
#define PATH_SITELOADSEARCH
"%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"

nt/msysconfig.sh --prefix="c:\\Program Files (x86)\\Emacs"
#define PATH_SITELOADSEARCH
"%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"

nt/msysconfig.sh --prefix="c:/Program Files (x86)/Emacs"
--enable-locallisppath="%emacs_dir%/../site-lisp;d:/wherever/site-lisp"
#define PATH_SITELOADSEARCH
"%emacs_dir%/../site-lisp/;d:/wherever/site-lisp"

nt/msysconfig.sh --prefix="c:/Program Files (x86)/Emacs"
--enable-locallisppath="%emacs_dir%/../site-lisp;/d/wherever/site-lisp"
#define PATH_SITELOADSEARCH
"%emacs_dir%/../site-lisp/;d:/wherever/site-lisp"

nt/msysconfig.sh --prefix="/usr/local"
--enable-locallisppath="/usr/local/share/my-site-lisp"
#define PATH_SITELOADSEARCH "%emacs_dir%/share/my-site-lisp"

[-- Attachment #1.2: Type: text/html, Size: 2368 bytes --]

[-- Attachment #2: msys-locallisppath-revised.patch --]
[-- Type: application/octet-stream, Size: 3666 bytes --]

=== modified file 'Makefile.in'
--- Makefile.in	2013-05-16 09:58:56 +0000
+++ Makefile.in	2013-06-02 10:31:58 +0000
@@ -318,14 +318,33 @@
 	  -e 's;\(#.*PATH_DOC\).*$$;\1 "${docdir}";') &&		\
 	${srcdir}/build-aux/move-if-change epaths.h.$$$$ src/epaths.h
 
-# Convert MSYS-style /x/foo file name into x:/foo that Windows can grok.
-msys_to_w32=sed -e 's,^/\([A-Za-z]\)/,\1:/,'
+# Convert MSYS-style /x/foo or x:\foo file name into x:/foo that Windows can grok.
+msys_to_w32=sed -e 's,\\\\,/,g' -e 's,^/\([A-Za-z]\)/,\1:/,'
+
+# Transform directory search path and its components. Original can
+# be MSYS or Windows style. Set path separator to ";", directory
+# separator to "/" and transform MSYS-style "/c/" to "c:/".
+# Remove empty path components and escape semicolons.
+msys_lisppath_to_w32=sed -e 's,\\\\,/,g' -e 's,\(^\|[:;]\)\([A-Za-z]\):/,\1/\2/,g'	\
+			 -e 's/:/;/g' -e 's,\(^\|;\)/\([A-Za-z]\)/,\1\2:/,g'	\
+			 -e 's/;\+/;/g' -e 's/^;//' -e 's/;$$//' -e 's/;/\\\\;/g'
+
+# Replace "${prefix}" with '%emacs_dir%' (expands to install directory at runtime).
+msys_prefix_subst=sed -e 's!\(^\|;\)'"$${prefixpattern}"'\([;/]\|$$\)!\1%emacs_dir%\2!g'
+
+# Quote sed special characters (except backslash and newline) with double backslash.
+msys_sed_sh_escape=sed -e 's/[];$$*.^[]/\\\\&/g'
 
 # The w32 build needs a slightly different editing, and it uses
 # nt/epaths.nt as the template.
+# Use the value of ${locallisppath} supplied by `configure',
+# to support the --enable-locallisppath argument.
 epaths-force-w32: FRC
 	@(w32srcdir=`echo "${srcdir}" | ${msys_to_w32}` ; 	\
+	  prefixpattern=`echo '${prefix}' | ${msys_to_w32} | ${msys_sed_sh_escape}` ; \
+	  locallisppath=`echo '${locallisppath}' | ${msys_lisppath_to_w32} | ${msys_prefix_subst}` ; \
 	  sed < ${srcdir}/nt/epaths.nt > epaths.h.$$$$		\
+	  -e 's;\(#.*PATH_SITELOADSEARCH\).*$$;\1 "'"$${locallisppath}"'";' \
 	  -e '/^.*#/s/@VER@/${version}/g' 			\
 	  -e '/^.*#/s/@CFG@/${configuration}/g' 		\
 	  -e "/^.*#/s|@SRC@|$${w32srcdir}|g") &&		\

=== modified file 'nt/epaths.nt'
--- nt/epaths.nt	2013-04-06 13:25:17 +0000
+++ nt/epaths.nt	2013-06-02 10:31:58 +0000
@@ -41,10 +41,10 @@
 #define PATH_LOADSEARCH "%emacs_dir%/share/emacs/@VER@/lisp;%emacs_dir%/share/emacs/@VER@/leim"
 
 /* Like PATH_LOADSEARCH, but contains the non-standard pieces.
-   These are the site-lisp directories, typically something like
+   These are the site-lisp directories. Configure sets this to
+   ${locallisppath}, which typically defaults to something like:
    <datadir>/emacs/VERSION/site-lisp:<datadir>/emacs/site-lisp
-   Configure prepends any $locallisppath, as set by the
-   --enable-locallisppath argument.
+   but can be overridden by the --enable-locallisppath argument.
    This is combined with PATH_LOADSEARCH to make the default load-path.
    If the --no-site-lisp option is used, this piece is excluded.
 */

=== modified file 'src/epaths.in'
--- src/epaths.in	2013-01-01 09:11:05 +0000
+++ src/epaths.in	2013-06-02 10:31:58 +0000
@@ -30,10 +30,10 @@
 
 
 /* Like PATH_LOADSEARCH, but contains the non-standard pieces.
-   These are the site-lisp directories, typically something like
+   These are the site-lisp directories. Configure sets this to
+   ${locallisppath}, which typically defaults to something like:
    <datadir>/emacs/VERSION/site-lisp:<datadir>/emacs/site-lisp
-   Configure prepends any $locallisppath, as set by the
-   --enable-locallisppath argument.
+   but can be overridden by the --enable-locallisppath argument.
    This is combined with PATH_LOADSEARCH to make the default load-path.
    If the --no-site-lisp option is used, this piece is excluded.
 */

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Richard Copley]

[-- Attachment #1.1: Type: text/plain, Size: 651 bytes --]

On 2 June 2013 12:33, Richard Copley <rcopley@gmail.com> wrote:

> The attached patch supports both styles. The heuristics didn't turn
> out to be as hairy as I imagined.
>

But my patch is not pretty. I'd be glad to attempt to improve it if there
are any suggestions.

One last time I'll advocate the change I was thinking of initially: re-add
the "ROOT/../site-lisp" entry to PATH_SITELOADSEARCH in epaths.nt, as in
the attached patch.

It would be possible to add a similar entry for Unix-like systems (by
modifying locallisppath in configure.ac), but to me that seems a weird
thing to do. I have not considered the NS build that Stefan mentioned.

[-- Attachment #1.2: Type: text/html, Size: 1082 bytes --]

[-- Attachment #2: epaths-nt.patch --]
[-- Type: application/octet-stream, Size: 654 bytes --]

=== modified file 'nt/epaths.nt'
--- nt/epaths.nt	2013-04-06 13:25:17 +0000
+++ nt/epaths.nt	2013-06-04 18:19:19 +0000
@@ -48,7 +48,7 @@
    This is combined with PATH_LOADSEARCH to make the default load-path.
    If the --no-site-lisp option is used, this piece is excluded.
 */
-#define PATH_SITELOADSEARCH "%emacs_dir%/share/emacs/@VER@/site-lisp;%emacs_dir%/share/emacs/site-lisp"
+#define PATH_SITELOADSEARCH "%emacs_dir%/share/emacs/@VER@/site-lisp;%emacs_dir%/share/emacs/site-lisp;%emacs_dir%/../site-lisp"
 
 /* Like PATH_LOADSEARCH, but used only during the build process
    when Emacs is dumping.  Configure (using "make epaths-force") sets

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> Date: Tue, 4 Jun 2013 19:27:50 +0100
> From: Richard Copley <rcopley@gmail.com>
> 
> One last time I'll advocate the change I was thinking of initially: re-add
> the "ROOT/../site-lisp" entry to PATH_SITELOADSEARCH in epaths.nt, as in
> the attached patch.

I hear you, but please understand: it's not just addition of a
directory to the variable.  These directories are tested for existence
at startup, and Emacs displays a warning of any of them doesn't exist.
So, if the Windows build had a directory that other builds don't, we
would need Windows-specific code to ignore this specific directory if
it doesn't exist, or make sure it is created -- only on Windows -- at
"make install" time.  And since this list of directories is
constructed in a very convoluted way, paying attention to
EMACSLOADPATH in the environment and to whether Emacs is run
uninstalled, it is not easy to identify that single directory and
ignore it.

All this flies in the face of the main reason why I made the MSYS
build happen: remove as much Windows specific issues, code, and
configury, so that other developers and maintainers could understand
how the Windows port is built, and could make changes without fear
they break the Windows port too easily.  If we don't stick to this
attitude, the Windows port is in real danger of falling by the wayside
at the slightest change of fortunes.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

On 4 June 2013 20:37, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Tue, 4 Jun 2013 19:27:50 +0100
> > From: Richard Copley <rcopley@gmail.com>
> >
> > One last time I'll advocate the change I was thinking of initially:
> re-add
> > the "ROOT/../site-lisp" entry to PATH_SITELOADSEARCH in epaths.nt, as in
> > the attached patch.
>
> I hear you, but please understand: it's not just addition of a
> directory to the variable.  These directories are tested for existence
> at startup, and Emacs displays a warning of any of them doesn't exist.
> So, if the Windows build had a directory that other builds don't, we
> would need Windows-specific code to ignore this specific directory if
> it doesn't exist, or make sure it is created -- only on Windows -- at
> "make install" time.  And since this list of directories is
> constructed in a very convoluted way, paying attention to
> EMACSLOADPATH in the environment and to whether Emacs is run
> uninstalled, it is not easy to identify that single directory and
> ignore it.
>
> All this flies in the face of the main reason why I made the MSYS
> build happen: remove as much Windows specific issues, code, and
> configury, so that other developers and maintainers could understand
> how the Windows port is built, and could make changes without fear
> they break the Windows port too easily.  If we don't stick to this
> attitude, the Windows port is in real danger of falling by the wayside
> at the slightest change of fortunes.
>

Okay, I can swallow that, thanks for the explanation.

Would it be doable and generally useful to take account of an
EMACSSITELOADPATH environment variable, on all platforms?

[-- Attachment #2: Type: text/html, Size: 2200 bytes --]

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Glenn Morris]

Richard Copley wrote:

> Would it be doable and generally useful to take account of an
> EMACSSITELOADPATH environment variable, on all platforms?

That is basically (IMO a less good version of)

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12100

which I think is a reasonable request, but not straightforward to
implement, owing to the messy way this stuff works; and not a high
priority since -L works.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> Date: Sun, 2 Jun 2013 12:33:08 +0100
> From: Richard Copley <rcopley@gmail.com>
> 
> > Date: Sat, 1 Jun 2013 18:25:14 +0100
> > From: Richard Copley <rcopley@gmail.com>
> > [...] that's not possible without resorting to
> > heuristics, because ${locallisppath} is potentially a ":"-separated path.
> 
> The attached patch supports both styles. The heuristics didn't turn
> out to be as hairy as I imagined.
> 
> A few test cases:
> 
> nt/msysconfig.sh
> #define PATH_SITELOADSEARCH
> "%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"
> 
> nt/msysconfig.sh --prefix c:/emacs/emacs-112809
> #define PATH_SITELOADSEARCH
> "%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"
> 
> nt/msysconfig.sh --prefix="c:\\Program Files (x86)\\Emacs"
> #define PATH_SITELOADSEARCH
> "%emacs_dir%/share/emacs/24.3.50/site-lisp;%emacs_dir%/share/emacs/site-lisp"
> 
> nt/msysconfig.sh --prefix="c:/Program Files (x86)/Emacs"
> --enable-locallisppath="%emacs_dir%/../site-lisp;d:/wherever/site-lisp"
> #define PATH_SITELOADSEARCH
> "%emacs_dir%/../site-lisp/;d:/wherever/site-lisp"
> 
> nt/msysconfig.sh --prefix="c:/Program Files (x86)/Emacs"
> --enable-locallisppath="%emacs_dir%/../site-lisp;/d/wherever/site-lisp"
> #define PATH_SITELOADSEARCH
> "%emacs_dir%/../site-lisp/;d:/wherever/site-lisp"
> 
> nt/msysconfig.sh --prefix="/usr/local"
> --enable-locallisppath="/usr/local/share/my-site-lisp"
> #define PATH_SITELOADSEARCH "%emacs_dir%/share/my-site-lisp"

Thanks, I committed this (with ChangeLog entries) in your name.

Please note that these patches all but exhausted the limit on the
patches we can accept without your signing of legal papers.  So
additional contributions (which will be most welcome) will need
paperwork to be sent to the FSF copyright clerk.

Thanks again for working on this.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 179 bytes --]

On 7 June 2013 09:14, Eli Zaretskii <eliz@gnu.org> wrote:

> Thanks, I committed this (with ChangeLog entries) in your name.
>
Cool. I'm disproportionately proud of that. Thanks.

[-- Attachment #2: Type: text/html, Size: 483 bytes --]

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Juanma Barranquero]

On Fri, May 31, 2013 at 8:20 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> I'd prefer to poll users whether they use that ../site-lisp directory,
> before adding this to the instructions.  I suspect very few do, which
> would mean we make the instructions more complex than they already
> are.

I use ../site-lisp all the time. In /Devel/emacs/repo (which is the
shared bzr repo) I have site-lisp, and the checkouts for emacs-24, an
optimized build of trunk, a debug one, etc. (all built in-place). I
also have older releases, but they don't cause me trouble with .elc
because when I run an older Emacs is usually to check something and I
run them under -Q (or -q --no-site-file).

With the MSYS build, I don't really want to do "make install" (too
slow), and if I do, it's in-place, so the ability to share
installation dirs between releases does not really do anything for me
(not that is not a great feature, just that it doesn't match my use).

I hadn't noticed yet that ../site-lisp wasn't now on the load path. I
could work around it by deleting share/emacs/site-lisp and symlinking
it to ../site-lisp, but then I risk deleting my ../site-lisp when
removing an old working copy. Not a good idea.

So count this as a belated vote for, at least, documenting
--enable-locallisppath

   J

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 5 Jun 2013 01:55:32 +0200
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, rcopley@gmail.com, 14513@debbugs.gnu.org
> 
> I use ../site-lisp all the time. In /Devel/emacs/repo (which is the
> shared bzr repo) I have site-lisp, and the checkouts for emacs-24, an
> optimized build of trunk, a debug one, etc. (all built in-place). I
> also have older releases, but they don't cause me trouble with .elc
> because when I run an older Emacs is usually to check something and I
> run them under -Q (or -q --no-site-file).
> 
> With the MSYS build, I don't really want to do "make install" (too
> slow)

If "make install" is too slow, perhaps try disabling compression of
Lisp and Info files.

> and if I do, it's in-place, so the ability to share installation
> dirs between releases does not really do anything for me (not that
> is not a great feature, just that it doesn't match my use).

Anyway, I see nothing specific to Windows in this usage pattern.

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Juanma Barranquero]

On Thu, Jun 6, 2013 at 5:37 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> If "make install" is too slow, perhaps try disabling compression of
> Lisp and Info files.

Already do. It still seems much slower than the old nt/makefile.w32-in
"make install".

> Anyway, I see nothing specific to Windows in this usage pattern.

Well, Windows-specific or not, it was a useful usage pattern, and I
would really like to continue using it. My preference would be that it
worked as before, but as a last resort I don't object to having to
pass --enable-locallisppath, but it does not work right now
(amussingly, if you pass
--enable-locallisppath=%emacs_dir%/../site-lisp, after "make install"
you get a directory called "%emacs_dir%").

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 7 Jun 2013 03:49:10 +0200
> Cc: rcopley@gmail.com, 14513@debbugs.gnu.org
> 
> as a last resort I don't object to having to pass
> --enable-locallisppath, but it does not work right now

I will commit Richard's changes soon, and then it will.

> (amussingly, if you pass
> --enable-locallisppath=%emacs_dir%/../site-lisp, after "make
> install" you get a directory called "%emacs_dir%").

"make install" doesn't accept the --enable-locallisppath option.
Perhaps you mean something like this:

  make install locallisppath=%emacs_dir%/../site-lisp

In that case, what you get is exactly what the current Makefile is
expected to do: it creates literally each directory in the value of
that variable.  The %..% part can only be interpreted correctly by
Emacs itself, as it needs special code to expand emacs_dir.

bug#14514: Fwd: bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]

On 30 May 2013 20:28, Eli Zaretskii <eliz@gnu.org> wrote:

> [Why private email?]
>
No reason at all, that was a mistake, I apologise. I hope you don't mind me
forwarding this to the list.


> > Date: Thu, 30 May 2013 20:14:35 +0100
> > From: Richard Copley <rcopley@gmail.com>
> >
> > > >   c:\>dir /B c:\emacs
> > > >   emacs-111818
> > > >   emacs-112125
> > > >   emacs-112416
> > > >   site-lisp
> > >
> > > You can still have separate directories like that, unless I'm missing
> > > something.  The directory structure below emacs-NNNNNN directories
> > > will be different, but that's all.
> > >
> >
> > Also the site-lisp directory will not be on the load-path.
>
> Your site-lisp won't, but the one in ROOT/share/emacs will.
>
> > I'm not actively using more than one build.
>
> Then why do you need separate trees?  That's the only reason why you
> need the site-lisp outside of the Emacs tree.  Use the Posix-standard
> structure and one root for all the Emacs installations, and the
> problem is gone, because you have the common site-lisp directory in
> ROOT/share/emacs.
>
> > > it should be easy to create a simple script that, given a root
> > > directory and a version, will delete the subdirectories that belong to
> > > that version only.  There aren't too many directories to delete,
> > > basically libexec/emacs/VERSION and share/emacs/VERSION.  That, and
> > > the emacs-VERSION*.exe executables in bin/.
> > >
> > > Did I miss something?
> > >
> >
> > With the uninstallation? No idea. It's ok, there's no way I'll be doing
> > that.
>
> You mean, you will never uninstall?  Then why do you keep the versions
> separate?
>
> > > The new structure has advantages which I described in that mail in
> > > March.
> >
> > (1) You're the first one I know about who thinks that's important.
>
> Well, maybe I'm the only one who works on so many platforms.
>
> > (2) is wrong.
>
> It's not wrong as long as you keep all the installations under the
> same root, like /usr/local on Unix.
>
> > (3) I don't follow. Other platforms, really?
>
> Yes.  Imagine that your --prefix is on a networked volume that can be
> accessed from Windows and Unix systems alike.  Then only the
> architecture-dependent files (binaries) need to be separate;
> everything under %emacs_dir%/share/emacs/ can be installed only once
> and used by Emacs from any OS.
>

[-- Attachment #2: Type: text/html, Size: 3369 bytes --]

bug#14513: Fwd: bug#14513: 24.3.50; Site load-path pieces differ in MSYS build

[Richard Copley]

[-- Attachment #1: Type: text/plain, Size: 3285 bytes --]

Damn damn damn. I meant to forward this message to this bug, but
instead I sent it to bug-gnu-emacs@gnu.org. Sorry.

Eli, I didn't mean to reply by private email, and I re-sent my reply
to the list shortly afterwards, as you will have seen by now. I hope
you don't mind me forwarding your reply, which is below, with my
comments inline.

Sorry again for causing extra confusion. I've done similar things on
this list several times before. It's entirely unintentional.  The
Google mail interface makes it very easy to hit reply and slightly
annoying to hit reply-all.

---------- Forwarded message ----------
From: Richard Copley <rcopley@gmail.com>
Date: 30 May 2013 20:29
Subject: Fwd: bug#14513: 24.3.50; Site load-path pieces differ in MSYS build
To: "bug-gnu-emacs@gnu.org" <bug-gnu-emacs@gnu.org>


On 30 May 2013 20:28, Eli Zaretskii <eliz@gnu.org> wrote:

> [Why private email?]
>
> Date: Thu, 30 May 2013 20:14:35 +0100
> > From: Richard Copley <rcopley@gmail.com>
> >
> > > >   c:\>dir /B c:\emacs
> > > >   emacs-111818
> > > >   emacs-112125
> > > >   emacs-112416
> > > >   site-lisp
> > >
> > > You can still have separate directories like that, unless I'm missing
> > > something.  The directory structure below emacs-NNNNNN directories
> > > will be different, but that's all.
> > >
> >
> > Also the site-lisp directory will not be on the load-path.
>
> Your site-lisp won't, but the one in ROOT/share/emacs will.
>

Yes.


>
> > I'm not actively using more than one build.
>
> Then why do you need separate trees?  That's the only reason why you
> need the site-lisp outside of the Emacs tree.


I don't need separate trees. I find separate trees convenient.


> Use the Posix-standard
> structure and one root for all the Emacs installations, and the
> problem is gone, because you have the common site-lisp directory in
> ROOT/share/emacs.
>

That has its own disadvantages. Are we going round in circles?

> > it should be easy to create a simple script that, given a root
> > directory and a version, will delete the subdirectories that belong to
> > that version only.  There aren't too many directories to delete,
> > basically libexec/emacs/VERSION and share/emacs/VERSION.  That, and
> > the emacs-VERSION*.exe executables in bin/.
> >
> > Did I miss something?
> >
>
> With the uninstallation? No idea. It's ok, there's no way I'll be doing
> that.

You mean, you will never uninstall?  Then why do you keep the versions
> separate?
>

No that's not what I mean.

> > The new structure has advantages which I described in that mail in
> > > March.
> >
> > (1) You're the first one I know about who thinks that's important.
>
> Well, maybe I'm the only one who works on so many platforms.
>
> (2) is wrong.
>
> It's not wrong as long as you keep all the installations under the
> same root, like /usr/local on Unix.
>

That's true.

> (3) I don't follow. Other platforms, really?
>
> Yes.  Imagine that your --prefix is on a networked volume that can be
> accessed from Windows and Unix systems alike.  Then only the
> architecture-dependent files (binaries) need to be separate;
> everything under %emacs_dir%/share/emacs/ can be installed only once
> and used by Emacs from any OS.
>

No, you've lost me ... Do you actually do that? Where do the binaries go?

[-- Attachment #2: Type: text/html, Size: 5758 bytes --]