Directory structure changes in Emacs installed on MS-Windows

Directory structure changes in Emacs installed on MS-Windows

[Eli Zaretskii]

As part of my work on building the native MS-Windows Emacs using the
Posix configury and Makefile's, I intend to change the structure of
the installed Emacs directory tree, so that it more closely resembles
installations on Posix systems.  The details are below.

Does anyone see any disadvantages in making these changes?

Here's what the installed Emacs directory tree will look like:

  %emacs_dir%/bin -- binaries that users invoke: emacs.exe,
                     runemacs.exe, etags.exe, ctags.exe, addpm.exe

  %emacs_dir%/libexec/emacs/VERSION/i686-pc-mingw32 --
                     auxiliary binaries that Emacs invokes:
                     cmdproxy.exe, hexl.exe, ddeclient.exe

  %emacs_dir%/share/info -- Info manuals

  %emacs_dir%/share/man -- man pages

  %emacs_dir%/share/emacs/VERSION/lisp -- Lisp files

  %emacs_dir%/share/emacs/VERSION/leim -- Leim files

  %emacs_dir%/share/emacs/VERSION/site-lisp -- site-specific Lisp

  %emacs_dir%/share/emacs/VERSION/etc -- architecture-independent
                     files: DOC, tutorials, image files, themes, etc.

  %emacs_dir%/var/games/emacs -- Emacs game score files

%emacs_dir% stands for whatever directory Emacs is installed in, and
VERSION stands for the Emacs version, like 25.5.

The advantages of this arrangement, as I see them, are (1) it follows
the installation tree on Posix platforms, so will make things easier
for those who work on both kinds of platforms; (2) it will become
possible to have several Emacs versions installed that can be invoked
without any need to tweak PATH or rename the DOC file; (3) it will be
possible to share the installation tree with other platforms,
e.g., install Emacs on some remote volume shared via a network.

Comments?

Re: Directory structure changes in Emacs installed on MS-Windows

[Xue Fuqiao]

On Thu, 04 Apr 2013 20:45:02 +0300
Eli Zaretskii <eliz@gnu.org> wrote:

> As part of my work on building the native MS-Windows Emacs using the
> Posix configury and Makefile's, I intend to change the structure of
> the installed Emacs directory tree, so that it more closely resembles
> installations on Posix systems.

> Here's what the installed Emacs directory tree will look like:
>   %emacs_dir%/bin -- binaries that users invoke: emacs.exe,
>                      runemacs.exe, etags.exe, ctags.exe, addpm.exe
>   %emacs_dir%/libexec/emacs/VERSION/i686-pc-mingw32 --
>                      auxiliary binaries that Emacs invokes:
>                      cmdproxy.exe, hexl.exe, ddeclient.exe
>   %emacs_dir%/share/info -- Info manuals
>   %emacs_dir%/share/man -- man pages
>   %emacs_dir%/share/emacs/VERSION/lisp -- Lisp files
>   %emacs_dir%/share/emacs/VERSION/leim -- Leim files
>   %emacs_dir%/share/emacs/VERSION/site-lisp -- site-specific Lisp
>   %emacs_dir%/share/emacs/VERSION/etc -- architecture-independent
>                      files: DOC, tutorials, image files, themes, etc.
>   %emacs_dir%/var/games/emacs -- Emacs game score files
> %emacs_dir% stands for whatever directory Emacs is installed in, and
> VERSION stands for the Emacs version, like 25.5.
 
+1

-- 
Xue Fuqiao
http://www.gnu.org/software/emacs/

Re: Directory structure changes in Emacs installed on MS-Windows

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

> As part of my work on building the native MS-Windows Emacs using the
> Posix configury and Makefile's, I intend to change the structure of
> the installed Emacs directory tree, so that it more closely resembles
> installations on Posix systems.  The details are below.
>
>
> Does anyone see any disadvantages in making these changes?

I gather we will just need %emacs_dir%/bin in Windows PATH (as we need
now), not also %emacs_dir%/libexec/emacs/VERSION/i686-pc-mingw32 (emacs
will put the latter in exec-path by default).

If that's true, then I see no problem.

> The advantages of this arrangement, as I see them, are 

You left out:

(0) it simplifies the task of using the Posix configury

I think that's important.

> (1) it follows the installation tree on Posix platforms, so will make
> things easier for those who work on both kinds of platforms;

Yes, but only minimally. I work on both platforms currently, and have
never noticed that the Windows install was non-standard. 

I think that's because Posix doesn't have %emacs_dir% as the root, so I
already think of Windows as being "just different".

> (2) it will become possible to have several Emacs versions installed
> that can be invoked without any need to tweak PATH or rename the DOC
> file; 

I don't follow this; there is only one place for emacs.exe. Currently I
handle this by using a different %emacs_dir% for each emacs version.

I guess you could have %emacs_dir%/bin/emacs-VERSION.exe ? Does the
Posix install do that (I've seen that convention for some tools).

When I install an alternate Emacs version on a Posix system, I put it in
/usr/local/bin, with the original in /usr/bin.

-- 
-- Stephe

Re: Directory structure changes in Emacs installed on MS-Windows

[Andy Moreton]

On Thu 04 Apr 2013, Eli Zaretskii wrote:

> As part of my work on building the native MS-Windows Emacs using the
> Posix configury and Makefile's, I intend to change the structure of
> the installed Emacs directory tree, so that it more closely resembles
> installations on Posix systems.  The details are below.
>
> Does anyone see any disadvantages in making these changes?
>
> Here's what the installed Emacs directory tree will look like:
>
>   %emacs_dir%/bin -- binaries that users invoke: emacs.exe,
>                      runemacs.exe, etags.exe, ctags.exe, addpm.exe
>
>   %emacs_dir%/libexec/emacs/VERSION/i686-pc-mingw32 --
>                      auxiliary binaries that Emacs invokes:
>                      cmdproxy.exe, hexl.exe, ddeclient.exe
>
>   %emacs_dir%/share/info -- Info manuals
>
>   %emacs_dir%/share/man -- man pages
>
>   %emacs_dir%/share/emacs/VERSION/lisp -- Lisp files
>
>   %emacs_dir%/share/emacs/VERSION/leim -- Leim files
>
>   %emacs_dir%/share/emacs/VERSION/site-lisp -- site-specific Lisp
>
>   %emacs_dir%/share/emacs/VERSION/etc -- architecture-independent
>                      files: DOC, tutorials, image files, themes, etc.
>
>   %emacs_dir%/var/games/emacs -- Emacs game score files
>
> %emacs_dir% stands for whatever directory Emacs is installed in, and
> VERSION stands for the Emacs version, like 25.5.
>
> The advantages of this arrangement, as I see them, are (1) it follows
> the installation tree on Posix platforms, so will make things easier
> for those who work on both kinds of platforms; (2) it will become
> possible to have several Emacs versions installed that can be invoked
> without any need to tweak PATH or rename the DOC file; (3) it will be
> possible to share the installation tree with other platforms,
> e.g., install Emacs on some remote volume shared via a network.
>
> Comments?

This all looks sensible to me.

I assume that you are doing this work with MSYS. Using the Posix
configury would also work for using the win32 hosted mingw64 compilers
with MSYS, and also for the cygwin hosted mingw64 cross compilers.

Getting the cygwin hosted cross compilers working would then be a
stepping stone to getting linux hosted mingw64 cross compilers
working (after sorting out how to handle dumping in a cross build).

    AndyM

Re: Directory structure changes in Emacs installed on MS-Windows

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@member.fsf.org>
> Date: Thu, 04 Apr 2013 19:03:41 -0400
> 
> I gather we will just need %emacs_dir%/bin in Windows PATH (as we need
> now), not also %emacs_dir%/libexec/emacs/VERSION/i686-pc-mingw32 (emacs
> will put the latter in exec-path by default).

Yes, that's true.  This is done automatically at startup time.

> You left out:
> 
> (0) it simplifies the task of using the Posix configury
> 
> I think that's important.

It would be important if it were true, but I don't think it's true.
The way epaths.h is generated from epaths.in on Posix platforms leaves
the root of the Emacs installation tree (specified via --prefix)
hard-coded into the binary, and Emacs (AFAIK) currently doesn't
support relocation of the installation tree on Posix systems.  By
contrast, on Windows relocation is a matter of routine.  So I cannot
use the epaths-force target of the top-level Makefile anyway.

> > (2) it will become possible to have several Emacs versions installed
> > that can be invoked without any need to tweak PATH or rename the DOC
> > file; 
> 
> I don't follow this; there is only one place for emacs.exe. Currently I
> handle this by using a different %emacs_dir% for each emacs version.
> 
> I guess you could have %emacs_dir%/bin/emacs-VERSION.exe ? Does the
> Posix install do that (I've seen that convention for some tools).

Yes, the Posix install creates a symlink emacs-VERSION, and so will
the Windows one (except that instead of a symlink there will be a
copy).

Re: Directory structure changes in Emacs installed on MS-Windows

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Fri, 05 Apr 2013 00:16:56 +0100
> 
> I assume that you are doing this work with MSYS.

Yes, of course.

> Using the Posix configury would also work for using the win32 hosted
> mingw64 compilers with MSYS, and also for the cygwin hosted mingw64
> cross compilers.

It should, although I don't have these installed and probably won't
try them before merging the changes with the trunk.

> Getting the cygwin hosted cross compilers working would then be a
> stepping stone to getting linux hosted mingw64 cross compilers
> working (after sorting out how to handle dumping in a cross build).

Right.

Re: Directory structure changes in Emacs installed on MS-Windows

[chad]

On 04 Apr 2013, at 23:06, Eli Zaretskii <eliz@gnu.org> wrote:

> It would be important if it were true, but I don't think it's true.
> The way epaths.h is generated from epaths.in on Posix platforms leaves
> the root of the Emacs installation tree (specified via --prefix)
> hard-coded into the binary, and Emacs (AFAIK) currently doesn't
> support relocation of the installation tree on Posix systems.  By
> contrast, on Windows relocation is a matter of routine.  So I cannot
> use the epaths-force target of the top-level Makefile anyway.

I don't know if this is helpful to you or not, but the ns port
(--with-ns) features a relocatable tree.  It seems to be implemented
in src/nsterm.m, functions ns_etc_directory(), ns_exec_path(), and
ns_load_path().

~Chad

Re: Directory structure changes in Emacs installed on MS-Windows

[Eli Zaretskii]

> From: chad <yandros@MIT.EDU>
> Date: Fri, 5 Apr 2013 01:48:11 -0700
> Cc: "emacs-devel@gnu.org Development" <emacs-devel@gnu.org>
> 
> On 04 Apr 2013, at 23:06, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > It would be important if it were true, but I don't think it's true.
> > The way epaths.h is generated from epaths.in on Posix platforms leaves
> > the root of the Emacs installation tree (specified via --prefix)
> > hard-coded into the binary, and Emacs (AFAIK) currently doesn't
> > support relocation of the installation tree on Posix systems.  By
> > contrast, on Windows relocation is a matter of routine.  So I cannot
> > use the epaths-force target of the top-level Makefile anyway.
> 
> I don't know if this is helpful to you or not, but the ns port
> (--with-ns) features a relocatable tree.  It seems to be implemented
> in src/nsterm.m, functions ns_etc_directory(), ns_exec_path(), and
> ns_load_path().

Thanks, I know that.  Emacs on Windows is also already relocatable
(otherwise, we would have users outcry on our hands ;-).

What I was trying to say was that _because_ Emacs on Windows is, and
must continue to be, relocatable, the editing of epaths.in by the
configure script is pointless and just gets in the way, because the
result will most likely be thrown away at startup.  I think I will add
an alternative rule for src/epaths.h in the top-level Makefile.in for
the w32 build, and tweak configure.ac accordingly.

Re: Directory structure changes in Emacs installed on MS-Windows

[Stefan Monnier]

> It would be important if it were true, but I don't think it's true.
> The way epaths.h is generated from epaths.in on Posix platforms leaves
> the root of the Emacs installation tree (specified via --prefix)
> hard-coded into the binary, and Emacs (AFAIK) currently doesn't
> support relocation of the installation tree on Posix systems.
> By contrast, on Windows relocation is a matter of routine.  So I cannot
> use the epaths-force target of the top-level Makefile anyway.

FWIW, such a relocation issue came up with the NS port, and as
I pointed out back then, it would be better to do it once and for all
uniformly, i.e. also do that relocation for posix platforms.


        Stefan

Re: Directory structure changes in Emacs installed on MS-Windows

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Stephen Leake <stephen_leake@member.fsf.org>,  emacs-devel@gnu.org
> Date: Fri, 05 Apr 2013 09:19:21 -0400
> 
> > It would be important if it were true, but I don't think it's true.
> > The way epaths.h is generated from epaths.in on Posix platforms leaves
> > the root of the Emacs installation tree (specified via --prefix)
> > hard-coded into the binary, and Emacs (AFAIK) currently doesn't
> > support relocation of the installation tree on Posix systems.
> > By contrast, on Windows relocation is a matter of routine.  So I cannot
> > use the epaths-force target of the top-level Makefile anyway.
> 
> FWIW, such a relocation issue came up with the NS port, and as
> I pointed out back then, it would be better to do it once and for all
> uniformly, i.e. also do that relocation for posix platforms.

I believe you are talking about this:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11959#53

No one picked up that gauntlet.  One piece of the puzzle that is still
missing (at least as far as I'm concerned) for its solution is how to
reliably determine on Posix platforms the directory where the invoked
Emacs executable lives.  I vaguely remember that the value of argv[0]
is unreliable, and therefore even searching for it on PATH won't do.
How can that be done reliably?

Re: Directory structure changes in Emacs installed on MS-Windows

[Stefan Monnier]

> No one picked up that gauntlet.  One piece of the puzzle that is still
> missing (at least as far as I'm concerned) for its solution is how to
> reliably determine on Posix platforms the directory where the invoked
> Emacs executable lives.

100% reliable can't be done, I think.

> I vaguely remember that the value of argv[0] is unreliable, and
> therefore even searching for it on PATH won't do.

Indeed.  That's the best we can do, AFAIK.


        Stefan

Re: Directory structure changes in Emacs installed on MS-Windows

[Glenn Morris]

Eli Zaretskii wrote:

>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11959#53
>
> No one picked up that gauntlet.

I made a report for it! :)

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

Re: Directory structure changes in Emacs installed on MS-Windows

[chad]

On 05 Apr 2013, at 02:18, Eli Zaretskii <eliz@gnu.org> wrote:

> Thanks, I know that.  Emacs on Windows is also already relocatable
> (otherwise, we would have users outcry on our hands ;-).

Ah, I should have realized that when addpm.exe wasn't actually
essential.  Sorry for wasting your time.


On 05 Apr 2013, at 08:20, Glenn Morris <rgm@gnu.org> wrote:

> Eli Zaretskii wrote:
> 
>>  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11959#53
>> 
>> No one picked up that gauntlet.
> 
> I made a report for it! :)
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12123
> 


A bit of web-searching suggests an #ifdef-shotgun approach:

	http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe

I'm attempting to add this to Glenn's bug report.  I don't currently
have a good way to test on most of those platforms, unfortunately.

~Chad