bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Fri, 6 Mar 2015 17:35:02 -0800
> From: Ilya Zakharevich <ilya@math.berkeley.edu>
> Cc: 19989@debbugs.gnu.org
> 
> What IS important is the fact that the PATH of
>    bash --login
> won’t find the INSTALLED mingw.  Let me repeat the same stuff again:
> 
>   • mingw-get installs mingw into
>       FOO/bin
>     (here FOO is the install path set in mingw-get)
>   • /etc/profile’s PATH contains
>        /mingw/bin
>        /bin
>     (among others) — but /mingw/bin is actually resolved (AFAICS) to
>        FOO/msys/1.0/mingw/bin
>     (and /bin to FOO/msys/1.0/bin).
> 
>   • Therefore, /mingw/bin is on PATH, but it is a non-existing
>     directory (even after mangling).
> 
>   • Now there are two cases of the PATH at start of `bash --login´:
>        ∘ If PATH contains some other gcc, then the other gcc will be
>                used by ./configure — with hard-to-explain failures;
>        ∘ If PATH does not contain gcc, then ./configure will quickly
>          fail, reporting not finding gcc.

Repeating the same stuff over and over again won't get you anywhere
useful.  I understood what you wrote the first time.  But, as usual,
you didn't provide enough useful information that would allow a
bystander understand what causes a "wrong" GCC to be found, and which
"wrong" GCC was that.

IOW, stop hand-waving and start divulging useful information about the
broken setup you wound up with, and please do NOT withhold important
details on the pretense that they are "not important" (as if you
actually knew what is and what isn't).

So, let's try one more time, and this time try to provide full answers
with all the details:

 . In which directory do you have the MinGW gcc.exe?  Please make a
   point of showing its full absolute directory file name, both as
   seen by Windows native programs and by MSYS Bash.  Please do NOT
   substitute those stupid FOO placeholders, because they interfere
   with understanding the problem.
   In case you didn't know, to see the Windows-format file name of a
   directory that corresponds to some MSYS directory, you can do this
   in the MSYS Bash shell:

      $ cd /wherever/that/is && pwd -W

 . In which directory do you have the "wrong" gcc.exe?  Please provide
   the same details about that as for the MinGW gcc.exe.

 . What is the full value of PATH, in MSYS Bash and in the Windows
   cmd.exe shell?

 . Where do you have the MinGW headers and *.a libraries?  Please
   provide a full native Windows (not MSYS or Cygwin!) absolute file
   names of those directories.  Note that I'm talking about *.a
   libraries, not *.dll.  There should be at least 2 directories with
   them, one with libraries used by GCC, the other for linking against
   Windows w32 APIs and other external libraries, like image libraries
   and libxml.  (In most installations, there are actually 4
   directories, not 2; please list them all.)

 . If you installed any additional libraries that didn't come with
   MinGW, please provide the full absolute file names of the
   directories where you put their *.dll and *.a files, and their
   headers.  If you installed those libraries in the same directories
   where you have the MinGW headers and libraries, it's enough to
   mention that fact; no need to provide the directories explicitly.

 . Which packages did you select in mingw-get when you downloaded
   MinGW and MSYS?  Please provide a full list of those, and please
   make sure to point out which were selected by default, and which
   ones weren't and you yourself selected them.

 . Did mingw-get ask you any additional questions, apart of a single
   question in which directory to install the stuff?  If it did,
   please provide details of any non-default selections you made, or
   any other gestures you did while downloading and installing.

Armed with the above knowledge (assuming I'm going to get it), it is
just possible that we will succeed in arriving at the understanding of
what broke your installation, how to fix it, and how to avoid that in
the first place.  The latter part (if we ever get there) might help us
amend the instructions in nt/INSTALL, if there's something to amend
there.

> (After discovering this — which stole a couple of hours of my time) I
> needed to fix this.  Because the way of MSYS mangling of paths is not
> easily found, (and one cannot easily find MSYS’s /etc/profile),
> instead of editing PATH, I just modified the filesystem, linking
>   FOO/msys/1.0/mingw
> to
>   FOO/mingw
> (experiments show that this must be a Windows’ style link — made with
> sysinternal’s mklink, as reported).

AFAIK, mklink is not from SysInternals, it's a stock Windows program
that comes with every Windows box from Vista onward.  And at least for
creating symbolic links, it will trigger UAC elevation prompts (or
silently fail).  In any case, we are not going to ask users to install
SysInternals as a means to build Emacs.

And if what you intended is suggest that users be told to create a
junction point to "fix" this, then no, we won't do that, either.
Telling users to create junctions and symlinks is a bad idea, as it
confuses many Windows programs, certainly those which are result of
porting GNU and Unix stuff, which are usually built with symlink
support disabled, and so cannot detect loops in the filesystem that
links can create.  If there is a problem, we will have to find a way
of avoiding it without such kludges.

Now, are you up to the task of actually helping us to make the
instructions better?  Or all you want is to demonstrate how stupid and
inept we are?  If the former, we might get somewhere; if the latter,
there's nothing else to be said here.