From xemacs-m  Mon Dec 16 22:53:17 1996
Received: from susan.logware.de (root@susan.logware.de [192.109.80.15]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with SMTP id WAA28618 for <xemacs-beta@xemacs.org>; Mon, 16 Dec 1996 22:53:15 -0600 (CST)
Received: by susan.logware.de (Smail3.1.29.1)
	  id <m0vZrWi-0000AxC>; Tue, 17 Dec 96 05:53 MET
Message-Id: <m0vZrWi-0000AxC@susan.logware.de>
Date: Tue, 17 Dec 96 05:53 MET
From: Michael Diers <mdiers@logware.de>
To: XEmacs beta list <xemacs-beta@xemacs.org>
Subject: [19.15-b4] configure issues again, and another patch
In-Reply-To: <m29171k67m.fsf@altair.xemacs.org>
References: <m0vXpwo-0000AxC@susan.logware.de>
	<m0vYW7R-0000AxC@susan.logware.de>
	<199612132047.MAA00377@xemacs.eng.sun.com>
	<m29171k67m.fsf@altair.xemacs.org>

Steven L Baur <steve@miranova.com> wrote:

>>>>>> "Martin" == Martin Buchholz <mrb@eng.sun.com> writes:
>>>>>> "Michael" == Michael Diers <mdiers@logware.de> writes:

Michael> Michael Diers <mdiers@logware.de> wrote:
>>>> I still get bitten by the way we use cpp to generate
>>>> Makefile from Makefile.in.in.  [incoherent ramblings about
>>>> GNU cpp substituting strings containing `i386' by `1 ' on
>>>> i386 platforms deleted]

>  ...

Martin> I applied Michael's patch, but it's clear that the
Martin> current mechanism of running cpp on Makefiles, a job for
Martin> which cpp was never designed, is kludgy in the extreme.
Martin> It's not obvious what to replace it with, however.

> Michael's patch has been applied to 19.15.  --

Ooops. OK, so I stand accused of making poor Steven apply my
bogus patch in b4. Perhaps the patch below, which is against b4,
proves to be less awful. (The b4 situation is not so hot because
calling GNU cpp with argument -undef is plain wrong and is likely
to produce very broken makefiles. My apologies again.)

The new and improved patch below is very far from complete, of
course. It just illustrates a possible way to fight off cpp. Note
that the rather kludgy way of undefining certain macros likely to
cause trouble in the makefile templates could be replaced using
this scheme.

If we are to get rid of cpp altogether in this context, we are
probably in for major configure headaches. Please note that as of
now, we actually include system description files in the process
of building makefiles from Makefile.in.in templates. That's
because some configuration info is kept in the system description
files, e.g. which unexec method (and thus unexec object) to
use. Some of those files rely on cpp providing certain system
dependent information.

It appears to me that we should not keep this kind of data in
system description files. Instead, this information should be
provided by configure, and passed on to the makefile generation
process. That way we might eventually eliminate the need to run
cpp as the macro processor.

-Michael


*** configure.in-b4	Mon Dec 16 14:06:30 1996
--- configure.in	Tue Dec 17 00:01:00 1996
***************
*** 1537,1542 ****
--- 1537,1556 ----
  ### Eric Raymond says we should accept strings like "sysvr4" to mean
  ### "System V Release 4"; he writes, "The old convention encouraged
  ### confusion between `system' and `release' levels'."
+ ###
+ ### We rely on cpp to generate makefiles from Makefile.in.in templates.
+ ### There is at least one drawback to that. Since cpp generally has
+ ### built-in macro definitions like `#define unix' or `#define i386',
+ ### we must be careful to prevent it from substituting these occurences
+ ### in certain places in the makefiles. Pathnames for architecture-
+ ### specific files come to mind.
+ ### This is where CPPFLAGS_MAKEFILEGEN comes in. We try to selectively
+ ### disable (potentially) predefined macros that we find to be part of
+ ### the configuration string. 
+ ### This is but a poor method to help us fight off cpp, but it covers
+ ### those cases that used to bite me. <mdiers@logware.de>
+ 
+ CPPFLAGS_MAKEFILEGEN=""  # we normally do not need any extra flags
  
  machine='' opsys='' unported=no need_dynodump=no
  case "${canonical}" in
***************
*** 2265,2270 ****
--- 2279,2285 ----
    ## Intel 386 machines where we don't care about the manufacturer
    i[3-9]86-*-* )
      machine=intel386
+     CPPFLAGS_MAKEFILEGEN="${CPPFLAGS_MAKEFILEGEN} -Ui386"
      case "${canonical}" in
        *-isc1.* | *-isc2.[01]* )	opsys=386-ix ;;
        *-isc2.2* )		opsys=isc2-2 ;;
***************
*** 2295,2302 ****
  		else
  			NON_GNU_CPP="/lib/cpp -D_XOPEN_SOURCE"  ;
  		fi ;;
!       *-386bsd* )	        opsys=386bsd ;;
!       *-freebsd* )		opsys=freebsd ;;
        *-nextstep* )		opsys=nextstep ;;
        ## Otherwise, we'll fall through to the generic opsys code at the bottom.
      esac
--- 2310,2317 ----
  		else
  			NON_GNU_CPP="/lib/cpp -D_XOPEN_SOURCE"  ;
  		fi ;;
!       *-386bsd* )               opsys=386bsd ;;
!       *-freebsd* )              opsys=freebsd ;;
        *-nextstep* )		opsys=nextstep ;;
        ## Otherwise, we'll fall through to the generic opsys code at the bottom.
      esac
***************
*** 2540,2553 ****
  #### Now that we know whether we are using GCC, we can decide whether
  #### to use that one.
  
! #### Also, GNU CPP by default defines certain add'l macros that could
! #### hurt us when generating makefiles. We want to switch off these
! #### add'l macros for the purpose of generating makefiles.
! 
! CPPFLAGS_MAKEFILEGEN=""
! if [ "x$GCC" = x1 ] ; then
!   CPPFLAGS_MAKEFILEGEN=" -undef "
! elif [ "x$NON_GNU_CPP" = x ] ; then
    true
  else
    if [ "x$CPP" = x ]; then
--- 2555,2561 ----
  #### Now that we know whether we are using GCC, we can decide whether
  #### to use that one.
  
! if [ "x$GCC" = x1 ] || [ "x$NON_GNU_CPP" = x ] ; then
    true
  else
    if [ "x$CPP" = x ]; then

