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

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

[Yavor Doganov]

This change

2008-08-01  Adrian Robert  <Adrian.B.Robert@gmail.com>

        * nsterm.h (NSInteger, NSUInteger): Add defines for non-Leopard.


breaks the GNUstep build with GNUstep Base 1.16.1 on GNU/Linux:

In file included from nsterm.m:37:
nsterm.h:368: error: conflicting types for ‘NSInteger’
/usr/include/GNUstep/Foundation/NSObjCRuntime.h:40: error: previous declaration of ‘NSInteger’ was here
nsterm.h:369: error: conflicting types for ‘NSUInteger’
/usr/include/GNUstep/Foundation/NSObjCRuntime.h:41: error: previous declaration of ‘NSUInteger’ was here

,---- <Foundation/NSObjCRuntime.h> ----
| typedef gsaddr  NSInteger;
| typedef gsuaddr NSUInteger;
`--------------------------------------

Also,

2008-08-01  Chong Yidong  <cyd@stupidchicken.com>

        * nsterm.m (EmacsApp -application:openFiles:): GNUStep does not
        define NSApplicationDelegateReplySuccess.
        (EmacsView -converstationIdentifier): Use long instead of
        NSInteger for GNUStep, since it doesn't have NSInteger.
		      	       	     	^^^^^^^^^^^^^^^^^^^^^^

is not true as of Base 1.15.3 (unstable) and 1.16.0 (stable, released
on 15th Jun 2008):

2008-02-25  Richard Frith-Macdonald <rfm@gnu.org>

        * Headers/Foundation/NSObjCRuntime.h: Added NSInteger and NSUInteger
        for MacOSX compatibiulity.

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

[Chong Yidong]

Could you apply the following patch and see if it does the right thing?
It tries to detect the existence of NSInteger in configure.

*** trunk/configure.in.~1.552.~	2008-07-31 12:18:39.000000000 -0400
--- trunk/configure.in	2008-08-04 12:02:38.000000000 -0400
***************
*** 2046,2051 ****
--- 2046,2055 ----
    if test "${NS_IMPL_GNUSTEP}" = "yes"; then
      AC_DEFINE(NS_IMPL_GNUSTEP, 1, [Define to 1 if you are using NS windowing under GNUstep.])
    fi
+   AC_TRY_COMPILE([#include <Foundation/NSObjCRuntime.h>], [NSInteger i;], NS_HAVE_NSINTEGER=yes, NS_HAVE_NSINTEGER=no)
+   if test "${NS_HAVE_NSINTEGER}" = "yes"; then
+     AC_DEFINE(NS_HAVE_NSINTEGER, 1, [Define to 1 if `NSInteger' is defined.])
+   fi
    # We also have mouse menus.
    HAVE_MENUS=yes
  fi
*** trunk/configure~	2008-08-04 12:03:19.000000000 -0400
--- trunk/configure	2008-08-04 12:03:27.000000000 -0400
***************
*** 14849,14854 ****
--- 14849,14902 ----
  _ACEOF
  
    fi
+   cat >conftest.$ac_ext <<_ACEOF
+ /* confdefs.h.  */
+ _ACEOF
+ cat confdefs.h >>conftest.$ac_ext
+ cat >>conftest.$ac_ext <<_ACEOF
+ /* end confdefs.h.  */
+ #include <Foundation/NSObjCRuntime.h>
+ int
+ main ()
+ {
+ NSInteger i;
+   ;
+   return 0;
+ }
+ _ACEOF
+ rm -f conftest.$ac_objext
+ if { (ac_try="$ac_compile"
+ case "(($ac_try" in
+   *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+   *) ac_try_echo=$ac_try;;
+ esac
+ eval "echo \"\$as_me:$LINENO: $ac_try_echo\"") >&5
+   (eval "$ac_compile") 2>conftest.er1
+   ac_status=$?
+   grep -v '^ *+' conftest.er1 >conftest.err
+   rm -f conftest.er1
+   cat conftest.err >&5
+   echo "$as_me:$LINENO: \$? = $ac_status" >&5
+   (exit $ac_status); } && {
+ 	 test -z "$ac_c_werror_flag" ||
+ 	 test ! -s conftest.err
+        } && test -s conftest.$ac_objext; then
+   NS_HAVE_NSINTEGER=yes
+ else
+   echo "$as_me: failed program was:" >&5
+ sed 's/^/| /' conftest.$ac_ext >&5
+ 
+ 	NS_HAVE_NSINTEGER=no
+ fi
+ 
+ rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+   if test "${NS_HAVE_NSINTEGER}" = "yes"; then
+ 
+ cat >>confdefs.h <<\_ACEOF
+ #define NS_HAVE_NSINTEGER 1
+ _ACEOF
+ 
+   fi
    # We also have mouse menus.
    HAVE_MENUS=yes
  fi
*** trunk/src/nsterm.h.~1.9.~	2008-08-02 18:22:33.000000000 -0400
--- trunk/src/nsterm.h	2008-08-04 12:02:47.000000000 -0400
***************
*** 364,370 ****
  @end
  #endif
  
! #if defined (NS_IMPL_GNUSTEP) || ( defined (NS_IMPL_COCOA) && MAC_OS_X_VERSION_MAX_ALLOWED <= MAC_OS_X_VERSION_10_4)
  typedef long NSInteger;
  typedef unsigned long NSUInteger;
  #endif /* NS_IMPL_GNUSTEP || (NS_IMPL_COCOA and <= 10.4) */
--- 364,370 ----
  @end
  #endif
  
! #ifndef NS_HAVE_NSINTEGER
  typedef long NSInteger;
  typedef unsigned long NSUInteger;
  #endif /* NS_IMPL_GNUSTEP || (NS_IMPL_COCOA and <= 10.4) */

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

[Yavor Doganov]

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

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

[Yavor Doganov]

reopen 647
tags 647 + patch
thanks

I just tried with an older version of GNUstep Base (1.14.1) and
because of a typo in the fix of this bug, NS_HAVE_INTEGER is
unconditionally defined -- so the build fails.

*** configure.in	05 авг 2008 21:06:42 +0300	1.553
--- configure.in	05 авг 2008 21:07:00 +0300	
***************
*** 2054,2062 ****
    if test "${NS_IMPL_GNUSTEP}" = "yes"; then
      AC_DEFINE(NS_IMPL_GNUSTEP, 1, [Define to 1 if you are using NS windowing under GNUstep.])
    fi
!   dnl if test "${NS_HAVE_INTEGER}" = "yes"; then
      AC_DEFINE(NS_HAVE_INTEGER, 1, [Define to 1 if `NSInteger' is defined.])
!   dnl fi
    # We also have mouse menus.
    HAVE_MENUS=yes
  fi
--- 2054,2062 ----
    if test "${NS_IMPL_GNUSTEP}" = "yes"; then
      AC_DEFINE(NS_IMPL_GNUSTEP, 1, [Define to 1 if you are using NS windowing under GNUstep.])
    fi
!   if test "${NS_HAVE_INTEGER}" = "yes"; then
      AC_DEFINE(NS_HAVE_INTEGER, 1, [Define to 1 if `NSInteger' is defined.])
!   fi
    # We also have mouse menus.
    HAVE_MENUS=yes
  fi

bug#647: marked as done (23.0.60; NSInteger changes in nsterm.h break the GNUstep build)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]


Your message dated Mon, 11 Aug 2008 01:05:25 +0300
with message-id <87vdy88r16.GNU's_Not_Unix!%yavor@gnu.org>
and subject line Fixed
has caused the Emacs bug report #647,
regarding 23.0.60; NSInteger changes in nsterm.h break the GNUstep build
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
647: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=647
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3898 bytes --]

From: Yavor Doganov <yavor@gnu.org>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.60; NSInteger changes in nsterm.h break the GNUstep build
Date: Mon, 04 Aug 2008 17:24:28 +0300
Message-ID: <874p60g8o3.GNU's_Not_Unix!%yavor@gnu.org>

This change

2008-08-01  Adrian Robert  <Adrian.B.Robert@gmail.com>

        * nsterm.h (NSInteger, NSUInteger): Add defines for non-Leopard.


breaks the GNUstep build with GNUstep Base 1.16.1 on GNU/Linux:

In file included from nsterm.m:37:
nsterm.h:368: error: conflicting types for ‘NSInteger’
/usr/include/GNUstep/Foundation/NSObjCRuntime.h:40: error: previous declaration of ‘NSInteger’ was here
nsterm.h:369: error: conflicting types for ‘NSUInteger’
/usr/include/GNUstep/Foundation/NSObjCRuntime.h:41: error: previous declaration of ‘NSUInteger’ was here

,---- <Foundation/NSObjCRuntime.h> ----
| typedef gsaddr  NSInteger;
| typedef gsuaddr NSUInteger;
`--------------------------------------

Also,

2008-08-01  Chong Yidong  <cyd@stupidchicken.com>

        * nsterm.m (EmacsApp -application:openFiles:): GNUStep does not
        define NSApplicationDelegateReplySuccess.
        (EmacsView -converstationIdentifier): Use long instead of
        NSInteger for GNUStep, since it doesn't have NSInteger.
		      	       	     	^^^^^^^^^^^^^^^^^^^^^^

is not true as of Base 1.15.3 (unstable) and 1.16.0 (stable, released
on 15th Jun 2008):

2008-02-25  Richard Frith-Macdonald <rfm@gnu.org>

        * Headers/Foundation/NSObjCRuntime.h: Added NSInteger and NSUInteger
        for MacOSX compatibiulity.



[-- Attachment #3: Type: message/rfc822, Size: 1820 bytes --]

From: Yavor Doganov <yavor@gnu.org>
To: 647-done@emacsbugs.donarmstrong.com
Subject: Fixed
Date: Mon, 11 Aug 2008 01:05:25 +0300
Message-ID: <87vdy88r16.GNU's_Not_Unix!%yavor@gnu.org>

This bug was fixed by Chong Yidong; closing.