bug#647: 23.0.60; NSInteger changes in nsterm.h break the GNUstep build

[Yavor Doganov <yavor@gnu.org>]

Chong Yidong wrote:
> 
> Could you apply the following patch and see if it does the right
> thing?

No, it doesn't work; relevant part from config.log:

configure:14873: gcc -c  -O2 -D_BSD_SOURCE   conftest.c >&5
conftest.c:86:38: error: Foundation/NSObjCRuntime.h: No such file or directory
conftest.c: In function 'main':
conftest.c:90: error: 'NSInteger' undeclared (first use in this function)
conftest.c:90: error: (Each undeclared identifier is reported only once
conftest.c:90: error: for each function it appears in.)
conftest.c:90: error: expected ';' before 'i'
configure:14879: $? = 1
configure: failed program was:
(Please tell me if you need that relevantly long program)

Apparently it is not possible to check at this place in configure.in
where CPPFLAGS is already reset and do not include
-I/usr/include/GNUstep (and the current language is C).

Furthermore, is there a compelling reason to use the obsolete and
known to be broken macro AC_TRY_COMPILE?  Emacs' configure.in already
requires Autoconf 2.61 (which is a fairly modern release), and there
should be zero impact on users since only developers regenerate the
build system (and `configure' is kept in CVS anyway for those that
build Emacs from CVS and do not have a recent Autoconf release).

The following (roughly equivalent to your change) works for me:

--- configure.in	04 авг 2008 20:21:35 +0300	1.552
+++ configure.in	04 авг 2008 20:21:53 +0300	
@@ -1236,6 +1236,11 @@
      LDFLAGS="$LDFLAGS -L${GNUSTEP_SYSTEM_LIBRARIES}"
   fi
   AC_CHECK_HEADER(AppKit/AppKit.h, HAVE_NS=yes)
+  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([#include <Foundation/NSObjCRuntime.h>],
+   			             [NSInteger i;])],
+    		    [AC_DEFINE([NS_HAVE_INTEGER], [1],
+		               [Define to 1 if `NSInteger' is defined.])],
+	            [])
 fi
 if test "${HAVE_NS}" = yes; then
   window_system=nextstep