* Directory structure changes in Emacs installed on MS-Windows
@ 2013-04-04 17:45 Eli Zaretskii
2013-04-04 22:51 ` Xue Fuqiao
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Eli Zaretskii @ 2013-04-04 17:45 UTC (permalink / raw)
To: emacs-devel
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Directory structure changes in Emacs installed on MS-Windows
2013-04-04 17:45 Directory structure changes in Emacs installed on MS-Windows Eli Zaretskii
@ 2013-04-04 22:51 ` Xue Fuqiao
2013-04-04 23:03 ` Stephen Leake
2013-04-04 23:16 ` Andy Moreton
2 siblings, 0 replies; 13+ messages in thread
From: Xue Fuqiao @ 2013-04-04 22:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Directory structure changes in Emacs installed on MS-Windows
2013-04-04 17:45 Directory structure changes in Emacs installed on MS-Windows Eli Zaretskii
2013-04-04 22:51 ` Xue Fuqiao
@ 2013-04-04 23:03 ` Stephen Leake
2013-04-05 6:06 ` Eli Zaretskii
2013-04-04 23:16 ` Andy Moreton
2 siblings, 1 reply; 13+ messages in thread
From: Stephen Leake @ 2013-04-04 23:03 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Directory structure changes in Emacs installed on MS-Windows
2013-04-04 23:03 ` Stephen Leake
@ 2013-04-05 6:06 ` Eli Zaretskii
2013-04-05 8:48 ` chad
2013-04-05 13:19 ` Stefan Monnier
0 siblings, 2 replies; 13+ messages in thread
From: Eli Zaretskii @ 2013-04-05 6:06 UTC (permalink / raw)
To: Stephen Leake; +Cc: emacs-devel
> 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).
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Directory structure changes in Emacs installed on MS-Windows
2013-04-05 6:06 ` Eli Zaretskii
@ 2013-04-05 8:48 ` chad
2013-04-05 9:18 ` Eli Zaretskii
2013-04-05 13:19 ` Stefan Monnier
1 sibling, 1 reply; 13+ messages in thread
From: chad @ 2013-04-05 8:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel@gnu.org Development
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Directory structure changes in Emacs installed on MS-Windows
2013-04-05 8:48 ` chad
@ 2013-04-05 9:18 ` Eli Zaretskii
0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2013-04-05 9:18 UTC (permalink / raw)
To: chad; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Directory structure changes in Emacs installed on MS-Windows
2013-04-05 6:06 ` Eli Zaretskii
2013-04-05 8:48 ` chad
@ 2013-04-05 13:19 ` Stefan Monnier
2013-04-05 14:18 ` Eli Zaretskii
1 sibling, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2013-04-05 13:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stephen Leake, emacs-devel
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Directory structure changes in Emacs installed on MS-Windows
2013-04-05 13:19 ` Stefan Monnier
@ 2013-04-05 14:18 ` Eli Zaretskii
2013-04-05 15:19 ` Stefan Monnier
2013-04-05 15:20 ` Glenn Morris
0 siblings, 2 replies; 13+ messages in thread
From: Eli Zaretskii @ 2013-04-05 14:18 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Directory structure changes in Emacs installed on MS-Windows
2013-04-05 14:18 ` Eli Zaretskii
@ 2013-04-05 15:19 ` Stefan Monnier
2013-04-05 15:20 ` Glenn Morris
1 sibling, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2013-04-05 15:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Directory structure changes in Emacs installed on MS-Windows
2013-04-05 14:18 ` Eli Zaretskii
2013-04-05 15:19 ` Stefan Monnier
@ 2013-04-05 15:20 ` Glenn Morris
2013-04-05 17:32 ` chad
1 sibling, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2013-04-05 15:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Directory structure changes in Emacs installed on MS-Windows
2013-04-05 15:20 ` Glenn Morris
@ 2013-04-05 17:32 ` chad
0 siblings, 0 replies; 13+ messages in thread
From: chad @ 2013-04-05 17:32 UTC (permalink / raw)
To: Eli Zaretskii, emacs-devel@gnu.org Development
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Directory structure changes in Emacs installed on MS-Windows
2013-04-04 17:45 Directory structure changes in Emacs installed on MS-Windows Eli Zaretskii
2013-04-04 22:51 ` Xue Fuqiao
2013-04-04 23:03 ` Stephen Leake
@ 2013-04-04 23:16 ` Andy Moreton
2013-04-05 6:08 ` Eli Zaretskii
2 siblings, 1 reply; 13+ messages in thread
From: Andy Moreton @ 2013-04-04 23:16 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Directory structure changes in Emacs installed on MS-Windows
2013-04-04 23:16 ` Andy Moreton
@ 2013-04-05 6:08 ` Eli Zaretskii
0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2013-04-05 6:08 UTC (permalink / raw)
To: Andy Moreton; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-04-05 17:32 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-04 17:45 Directory structure changes in Emacs installed on MS-Windows Eli Zaretskii
2013-04-04 22:51 ` Xue Fuqiao
2013-04-04 23:03 ` Stephen Leake
2013-04-05 6:06 ` Eli Zaretskii
2013-04-05 8:48 ` chad
2013-04-05 9:18 ` Eli Zaretskii
2013-04-05 13:19 ` Stefan Monnier
2013-04-05 14:18 ` Eli Zaretskii
2013-04-05 15:19 ` Stefan Monnier
2013-04-05 15:20 ` Glenn Morris
2013-04-05 17:32 ` chad
2013-04-04 23:16 ` Andy Moreton
2013-04-05 6:08 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).