Re: fix the AC_USE_SYSTEM_EXTENSIONS regression.

[Eric Blake]

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

> > Unfortunately, now that 2.62 has been released, there are packages that
> > are relying on the new combined semantics (pretty much anything
> > gnulib-based),
> 
> What code expects AC_AIX to expand all of AC_USE_SYSTEM_EXTENSIONS?

Probably none.  But so far, the problem reports seem to be related to 
intererence between macros at m4 time, and not in the extra definitions added 
to config.h.  Also, we documented that AC_AIX is obsolete, because its real 
intent was to enable system extensions for a limited class of systems, and 
generally, portable programs that want to enable system extensions should do so 
for all platforms rather than singling out AIX, so expanding to all of 
AC_USE_SYSTEM_EXTENSIONS better fits that intent.

> And if not that, what is it exactly that the gnulib code expects?

Gnulib currently provides autoconf 2.62's definition of 
AC_USE_SYSTEM_EXTENSIONS as the extensions module, so that even if you are 
using autoconf 2.59, you are guaranteed that a single module (and thus single 
macro call) enables all known system extensions across all gnulib targets.  
Clients of the gnulib module extensions should therefore NOT call AC_AIX or 
other obsolete friends; for that matter, they shouldn't even directly call 
AC_USE_SYSTEM_EXTENSIONS because gl_EARLY does that on their behalf.

> 
> > as well as packages that aren't expecting the combined
> > semantics (witness all the bug reports).  I don't think straight reversion
> > is an option because it would impact a different set of packages;
> 
> Agreed; I didn't know about the gnulib requirements.

I hope we're too far off from a solution that meets everyone's needs.  Whatever 
we end up with, gnulib's extension module will have to be updated to pick up 
the new definition of AC_USE_SYSTEM_EXTENSIONS.

-- 
Eric Blake