Re: Possible patch for autoconf?

[Daniel Carroll]

> Please, keep things public, so that people can suggest solutions, so
> that archives hold relevant messages etc.

Will do.  Sorry.

More comments down below:

> | Here's what I see:
> | (I've taken some liberty in re-arranging the code, to try and
> |  make it a little clearer about what belongs to what...)
> | 
> | AC_DEFUN([_AC_PROG_PREPROC_WORKS_IFELSE],
> |  [
> |    ac_[]_AC_LANG_ABBREV[]_preproc_warn_flag=maybe
> |    _AC_PREPROC_IFELSE(
> |         [AC_LANG_SOURCE(address@hidden:@include <assert.h> Syntax error]])],
> |         [
> |           _AC_PREPROC_IFELSE(
> |         ^^^^^^^^^^^^^^^^^^^^^^
> |              [AC_LANG_SOURCE(address@hidden:@include <ac_nonexistent.h>]])],
> |              [ m4_default([$2], :) ],
> |              [
> |                if test "x$ac_cpp_err" = xmaybe; then
> |                  ac_[]_AC_LANG_ABBREV[]_preproc_warn_flag=yes
> |                else
> |                  ac_[]_AC_LANG_ABBREV[]_preproc_warn_flag=
> |                fi
> |                $1
> |              ]
> |           ) # End of _AC_PREPROC_IFELSE
> |         ],
> |         [ m4_default([$2], :) ]
> |    ) # End of _AC_PREPROC_IFELSE
> |  ]
> | ) # _AC_PROG_PREPROC_WORKS_IFELSE
> | 
> | 
> | At the indicated _AC_PREPROC_IFELSE, either just inside it, or
> | as the last thing before it's called, there is a check to
> | see if $ac_cpp_err is blank.  For compilers that print junk
> | on stdout (in my case, a copyright message), this is true, so
       ^^^^^^  Mistake on my part. (- Dan)
> | $ac_cpp_err is set to "maybe".  Since "maybe" is a non-blank
> | string, the script will not go down this codepath.
> 
> I'm a bit confused.  I think I understand what you mean, but first of
> all, stdout is not taken into account in here, so I must be missing
> something.

Oops!  That was a slip-up on my part.  I meant to say "stderr".  Sorry.

> And secondly if I understand correctly your diagnostic,
> you are referring to the innermost branch which holds $2, right?

The problem occurs just before the innermost _AC_PREPROC_IFELSE,
so I think the answer is no.

After thinking about it some more, I believe that the outer
_AC_PREPROC_IFELSE is going down the "else" codepath (which
calls "m4_default([$2], :)"), because it considers the 
  AC_LANG_SOURCE(address@hidden:@include <assert.h> Syntax error]])
construct to have failed for "cc -E" (because $ac_cpp_err is
set to "maybe").

> But then, this is the case of a broken CPP, so do we care?
> 
> What is exactly the problem you face?

On this particular system, it ships with a "non-standard" preprocessor
macro in my <limits.h> include file (and a couple of other include files
as well), that /lib/cpp will fail on, but 'cc -E' can parse it.

> Would it be possible that you submit a shell script that behaves like
> your cpp?

Sure: here's a script that does a (poor, but hopefully adequate) imitation
of "cc -E" on this particular computer:

#!/bin/sh
#
# Emulate the behaviour of "cc -E" on an NCR MP-RAS unix platform:
#
if [ $1 != "-E" ]; then
  echo "This script only emulates the C preprocessor!"
  exit 1;
fi
shift
echo "NCR High Performance C Compiler R3.0c" >&2
echo "(c) Copyright 1994-97, NCR Corporation" >&2
echo "(c) Copyright 1987-97, MetaWare Incorporated" >&2
/lib/cpp $*

>  Or better yet, getting inspired by the tests named 
> 
> ## --------------------------- ##
> ## AC_PROG_CPP with warnings.  ##
> ## --------------------------- ##
> 
> and
> 
> ## ------------------------------ ##
> ## AC_PROG_CPP without warnings.  ##
> ## ------------------------------ ##
> 
> in tests/compile.at, could you build another test that would help us
> first fixing the issue, and secondly, keep it fixed ``forever''?

So, what you would like me to do is add another test to the one under 
"AC_PROG_CPP with warnings", that will see if "CPP" is something 
besides "cc -E", and if it is, check to make sure that "cc -E" actually 
doesn't work, and display an error if "cc -E" does work?

        - Dan