On 09/05/13 13:36, Eric Blake wrote:
> On 05/08/2013 09:19 PM, Allan McRae wrote:
>> I believe autoconf uses "CPP CPPFLAGS" to detect headers mainly because
>> of "-I" flags needing to be considered. Would an acceptable solution at
>> the autoconf level be to split the CPPFLAGS into -I flags and others
>> (-D, -U) and just use the -I ones in the header test?
>>
>> If that is fine in principle, I can attempt to implement it.
>
> But that won't help you instantly fix the hundreds of existing packages
> whose configure script was generated with an earlier version of
> autoconf. While I am open to making future autoconf have saner behavior
> by default, you MUST consider the fact that your distro's choice of
> CFLAGS vs. CPPFLAGS is the real problem here ("if it hurts, don't do
> it"), rather than waiting for a patched autoconf to trickle down into
> fixed configure scripts on boatloads of packages.
I'm not worried about my distros choice of CPPFLAGS/CFLAGS. The flags
are being defined where they should be defined and working around it in
the relatively few software packages that this causes issues is a single
sed in the build script. Hiding the issue only delays it actually being
fixed at the source.
Saying that, it is really only an issue in a few places... I have
looked into why and it seems to be due to a choice of which
ac_fn_c_check_header_* functions is used. Looking in binutils (where
all configure files are generated with autoconf 2.64), the configure
files that fail use "ac_fn_c_check_header_preproc" while the ones that
succeed use "ac_fn_c_check_header_mongrel" or
"ac_fn_c_check_header_compile".
How is it determined which of those is used? From what I can tell
looking at the latest binutils source the working and failing
(libiberty) configure.ac files all use AC_CHECK_HEADERS.
Allan
_______________________________________________
Autoconf mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/autoconf
