More diagnostics for the W32 build

More diagnostics for the W32 build

[Eli Zaretskii]

I suggest the following changes to nt/configure.bat.  The purpose is
to leave behind a useful config.log file which could be perused to
find out why various parts of the configure stage failed.

This was tested on Windows XP SP2, but my main concern is about older
Windows versions, like Windows 9x: the changes use advanced
redirection features that are unavailable with COMMAND.COM, the
default shell that comes with those older versions of Windows.  OTOH,
the current version of configure.bat in CVS already uses features like
"2>junk.err", so I guess this causes some harmless error message?

I'll wait for Jason and others to comment on these changes, before I
decide whether to commit them.  TIA

--- configure.old	2005-06-04 12:32:38.000000000 +0300
+++ configure.bat	2005-06-04 14:29:51.703125000 +0300
@@ -47,6 +47,8 @@
 rem     cygwin provides this?
 rem
 
+if exist config.log del config.log
+
 rem ----------------------------------------------------------------------
 rem   See if the environment is large enough.  We need 43 (?) bytes.
 set $foo$=123456789_123456789_123456789_123456789_123
@@ -236,13 +238,17 @@
 echo Checking whether gcc requires '-mno-cygwin'...
 echo #include "cygwin/version.h" >junk.c
 echo main(){} >>junk.c
-gcc -c junk.c
+echo gcc -c junk.c >>config.log
+gcc -c junk.c >>config.log 2>&1
 if not exist junk.o goto chkapi
-gcc -mno-cygwin -c junk.c
+echo gcc -mno-cygwin -c junk.c >>config.log
+gcc -mno-cygwin -c junk.c >>config.log 2>&1
 if exist junk.o set nocygwin=Y
 rm -f junk.c junk.o
 
 :chkapi
+echo The failed program was: >>config.log
+type junk.c >>config.log
 rem ----------------------------------------------------------------------
 rem   Older versions of the Windows API headers either don't have any of
 rem   the IMAGE_xxx definitions (the headers that come with Cygwin b20.1
@@ -263,9 +269,13 @@
 :chkapi2
 echo on
 gcc %cf% -c junk.c
-echo off
+@echo off
+@echo gcc %cf% -c junk.c >>config.log
+gcc %cf% -c junk.c >>config.log 2>&1
 set cf=
 if exist junk.o goto gccOk
+echo The failed program was: >>config.log
+type junk.c >>config.log
 
 :nocompiler
 echo.
@@ -307,10 +317,13 @@
 echo #include "png.h" >junk.c
 echo main (){} >>junk.c
 rem   -o option is ignored with cl, but allows result to be consistent.
-%COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >junk.out 2>junk.err
+echo %COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >>config.log
+%COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >junk.out 2>>config.log
 if exist junk.obj goto havePng
 
 echo ...png.h not found, building without PNG support.
+echo The failed program was: >>config.log
+type junk.c >>config.log
 set HAVE_PNG=
 goto :pngDone
 
@@ -327,10 +340,13 @@
 echo #include "jconfig.h" >junk.c
 echo main (){} >>junk.c
 rem   -o option is ignored with cl, but allows result to be consistent.
-%COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >junk.out 2>junk.err
+echo %COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >>config.log
+%COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >junk.out 2>>config.log
 if exist junk.obj goto haveJpeg
 
 echo ...jconfig.h not found, building without JPEG support.
+echo The failed program was: >>config.log
+type junk.c >>config.log
 set HAVE_JPEG=
 goto :jpegDone
 
@@ -347,10 +363,13 @@
 echo #include "gif_lib.h" >junk.c
 echo main (){} >>junk.c
 rem   -o option is ignored with cl, but allows result to be consistent.
-%COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >junk.out 2>junk.err
+echo %COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >>config.log
+%COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >junk.out 2>>config.log
 if exist junk.obj goto haveGif
 
 echo ...gif_lib.h not found, building without GIF support.
+echo The failed program was: >>config.log
+type junk.c >>config.log
 set HAVE_GIF=
 goto :gifDone
 
@@ -367,10 +386,13 @@
 echo #include "tiffio.h" >junk.c
 echo main (){} >>junk.c
 rem   -o option is ignored with cl, but allows result to be consistent.
-%COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >junk.out 2>junk.err
+echo %COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >>config.log
+%COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >junk.out 2>>config.log
 if exist junk.obj goto haveTiff
 
 echo ...tiffio.h not found, building without TIFF support.
+echo The failed program was: >>config.log
+type junk.c >>config.log
 set HAVE_TIFF=
 goto :tiffDone
 
@@ -388,10 +410,13 @@
 echo #include "X11/xpm.h" >>junk.c
 echo main (){} >>junk.c
 rem   -o option is ignored with cl, but allows result to be consistent.
-%COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >junk.out 2>junk.err
+echo %COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >>config.log
+%COMPILER% %usercflags% %mingwflag% -c junk.c -o junk.obj >junk.out 2>>config.log
 if exist junk.obj goto haveXpm
 
 echo ...X11/xpm.h not found, building without XPM support.
+echo The failed program was: >>config.log
+type junk.c >>config.log
 set HAVE_XPM=
 goto :xpmDone

Re: More diagnostics for the W32 build

[jasonr]

Quoting Eli Zaretskii <eliz@gnu.org>:

> This was tested on Windows XP SP2, but my main concern is about older
> Windows versions, like Windows 9x: the changes use advanced
> redirection features that are unavailable with COMMAND.COM, the
> default shell that comes with those older versions of Windows.  OTOH,
> the current version of configure.bat in CVS already uses features like
> "2>junk.err", so I guess this causes some harmless error message?

Redirecting stderr works on COMMAND.COM as far as I recall. I'm not sure about
2>&1 though.

Re: More diagnostics for the W32 build

[Eli Zaretskii]

> Date: Sun,  5 Jun 2005 13:38:00 +0100
> From: jasonr@f2s.com
> Cc: emacs-devel@gnu.org
> 
> Redirecting stderr works on COMMAND.COM as far as I recall.

No, it doesn't.  "foo 2>bar" is interpreted as `foo' called with an
argument `2' and its stdout redirected to `bar'.  If you do that with
GCC, it complains about a non-existing file `2'.

> I'm not sure about 2>&1 though.

Definitely doesn't work, but does not prevent compilation, AFAICS.  So
I think it's safe to commit these changes.

Re: More diagnostics for the W32 build

[David Abrahams]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun,  5 Jun 2005 13:38:00 +0100
>> From: jasonr@f2s.com
>> Cc: emacs-devel@gnu.org
>> 
>> Redirecting stderr works on COMMAND.COM as far as I recall.
>
> No, it doesn't.  "foo 2>bar" is interpreted as `foo' called with an
> argument `2' and its stdout redirected to `bar'.  If you do that with
> GCC, it complains about a non-existing file `2'.
>
>> I'm not sure about 2>&1 though.
>
> Definitely doesn't work, 

That's strange; I use it all the time on Windows XP.  Seems to work
just fine (?)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: More diagnostics for the W32 build

[Lennart Borgman]

David Abrahams wrote:

>
>>>Redirecting stderr works on COMMAND.COM as far as I recall.
>>>      
>>>
>>No, it doesn't.  "foo 2>bar" is interpreted as `foo' called with an
>>argument `2' and its stdout redirected to `bar'.  If you do that with
>>GCC, it complains about a non-existing file `2'.
>>
>>    
>>
>>>I'm not sure about 2>&1 though.
>>>      
>>>
>>Definitely doesn't work, 
>>    
>>
>
>That's strange; I use it all the time on Windows XP.  Seems to work
>just fine (?)
>
Are you sure you mean command.com, not cmd.exe?

Re: More diagnostics for the W32 build

[David Abrahams]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Abrahams wrote:
>
>>
>>>>Redirecting stderr works on COMMAND.COM as far as I recall.
>>>>      
>>>>
>>>No, it doesn't.  "foo 2>bar" is interpreted as `foo' called with an
>>>argument `2' and its stdout redirected to `bar'.  If you do that with
>>>GCC, it complains about a non-existing file `2'.
>>>
>>>    
>>>
>>>>I'm not sure about 2>&1 though.
>>>>      
>>>>
>>> Definitely doesn't work,    
>>>
>>
>>That's strange; I use it all the time on Windows XP.  Seems to work
>>just fine (?)
>>
> Are you sure you mean command.com, not cmd.exe?

Nope, you're right.  Sorry for the noize.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: More diagnostics for the W32 build

[Eli Zaretskii]

> Date: Sat, 04 Jun 2005 16:40:10 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> I suggest the following changes to nt/configure.bat.  The purpose is
> to leave behind a useful config.log file which could be perused to
> find out why various parts of the configure stage failed.

No one objected, so I committed these changes.  Please tell me if you
find any problems with them.

In addition, I modified configure.bat and gmake.defs to use the
"-mtune=pentium4" compiler option if the installed GCC supports it,
instead of "-mcpu=i686" (the latter is still the default if -mtune or
pentium4 as its value are unsupported).  This takes care of the
annoying compiler warning about -mcpu being deprecated.  Again, if
this causes any trouble, including warnings, please let me know.