unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* More diagnostics for the W32 build
@ 2005-06-04 13:40 Eli Zaretskii
  2005-06-05 12:38 ` jasonr
  2005-06-11 11:06 ` Eli Zaretskii
  0 siblings, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2005-06-04 13:40 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: More diagnostics for the W32 build
  2005-06-04 13:40 More diagnostics for the W32 build Eli Zaretskii
@ 2005-06-05 12:38 ` jasonr
  2005-06-05 19:01   ` Eli Zaretskii
  2005-06-11 11:06 ` Eli Zaretskii
  1 sibling, 1 reply; 7+ messages in thread
From: jasonr @ 2005-06-05 12:38 UTC (permalink / raw)
  Cc: emacs-devel

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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: More diagnostics for the W32 build
  2005-06-05 12:38 ` jasonr
@ 2005-06-05 19:01   ` Eli Zaretskii
  2005-06-06 14:30     ` David Abrahams
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2005-06-05 19:01 UTC (permalink / raw)
  Cc: emacs-devel

> 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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: More diagnostics for the W32 build
  2005-06-05 19:01   ` Eli Zaretskii
@ 2005-06-06 14:30     ` David Abrahams
  2005-06-06 14:55       ` Lennart Borgman
  0 siblings, 1 reply; 7+ messages in thread
From: David Abrahams @ 2005-06-06 14:30 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: More diagnostics for the W32 build
  2005-06-06 14:30     ` David Abrahams
@ 2005-06-06 14:55       ` Lennart Borgman
  2005-06-06 15:55         ` David Abrahams
  0 siblings, 1 reply; 7+ messages in thread
From: Lennart Borgman @ 2005-06-06 14:55 UTC (permalink / raw)
  Cc: emacs-devel

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?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: More diagnostics for the W32 build
  2005-06-06 14:55       ` Lennart Borgman
@ 2005-06-06 15:55         ` David Abrahams
  0 siblings, 0 replies; 7+ messages in thread
From: David Abrahams @ 2005-06-06 15:55 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: More diagnostics for the W32 build
  2005-06-04 13:40 More diagnostics for the W32 build Eli Zaretskii
  2005-06-05 12:38 ` jasonr
@ 2005-06-11 11:06 ` Eli Zaretskii
  1 sibling, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2005-06-11 11:06 UTC (permalink / raw)


> 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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2005-06-11 11:06 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-04 13:40 More diagnostics for the W32 build Eli Zaretskii
2005-06-05 12:38 ` jasonr
2005-06-05 19:01   ` Eli Zaretskii
2005-06-06 14:30     ` David Abrahams
2005-06-06 14:55       ` Lennart Borgman
2005-06-06 15:55         ` David Abrahams
2005-06-11 11:06 ` 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).