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
