Re: [PATCH] OS X: make configure work better out of the box with FSF GCC

[Daniel Colascione <dan.colascione@gmail.com>]

On Mon, Feb 28, 2011 at 11:56 AM, Glenn Morris <rgm@gnu.org> wrote:
>
> Daniel Colascione wrote:
>
>> I didn't include the corresponding configure changes; I figure I can let
>> whoever installs this patch regenerate the script.
>
> Could you explain what problem this change is supposed to fix?

Various header files (right now, Carbon --- which, granted, isn't used
in the in-tree Emacs) presume that Apple-gcc specific features like
printf attributes for CFStrings work.  With FSF gcc (i.e., gcc without
Apple-specific patches) these declarations break the build.  Defining
__INTEL_COMPILER essentially tells the system to use only the set of
gcc extensions supported by icc, which is a subset of the extensions
supported by FSF GCC.

>
>> +    case "$(which "${CC-cc}")" in
>> +      /usr/bin/* | /usr/lib/* )
>> +        CPP="${CC-cc} -E -no-cpp-precomp"
>> +        ;;
>> +      * )
>> +        # The below macro prevents the Carbon headers from defining
>> +        # nonstandard constructs not understood by FSF GCC.
>> +        CPPFLAGS="$CPPFLAGS -D__INTEL_COMPILER=1"
>> +        CPP="${CC-cc} -E -D__INTEL_COMPILER=1"
>
> "FSF GCC" seems tautological at best.
>
> It seems fragile to test the location of the compiler. Why not test for
> the actual compiler version?
>

Apple essentially forked gcc 4.2, and it still reports that version.
I don't know a good way to distinguish Apple-patched gcc 4.2 from
FSF-issue gcc 4.2, and seeing whether the compiler is installed in the
"system compiler" location seems like a robust-enough way to figure
this out.  Another option would be to just do a test compilation, but
that takes time.