On 01/19/2013 06:10 AM, Stefano Lattarini wrote: > [-cc automake-patches] > > On 01/16/2013 06:48 PM, Paul Eggert wrote: >> On 01/16/13 04:46, Stefano Lattarini wrote: >>> Makes sense. Should I try to implement something along these lines (might >>> take a few days), or are you planning to do that yourself (in which case >>> I'll avoid the duplicated efforts)? >> >> I wasn't planning on doing that, so please go ahead. >> > Here is my attempt. OK to go in Autoconf 2.70?
Close, but I have some ideas for improvements. > > +- AC_PROG_CC_C_O implements saner semantics if the new witness macro > + AC_PROG_CC_C_O_USE_MODERN_SEMANTICS is defined (see the documentation > + for details). Future versions of autoconf might make such new > + semantics the default at some point. Thnking about a forward-compatibility issue - what happens if, when we switch semantics, someone still needs to get back to the old semantics? Do we add yet another witness macro at that time? And how does such a package work with both old and new autoconf at once? Rather, a better plan is to make AC_PROG_CC_C_O be configurable via a single witness, by taking an optional argument that determines _which_ semantics to use and having the witness be a non-empty string to alter defaults. All existing versions of autoconf ignore macro arguments to AC_PROG_CC_C_O, so we can add an optional argument, and document it as follows: =============== AC_PROG_CC_C_O([mode]) ---------------------- If MODE is given with the value 'sane', use the new semantics (for 2.70 and beyond). If MODE is given with the value 'old' (or for 2.69 and earlier), use the backwards-compatible semantics. If MODE is omitted, which of the two semantics will default to the value of the macro AC_PROG_CC_C_O_MODE (for 2.70 and beyond). AC_PROG_CC_C_O_MODE ------------------- This macro is predefined in autoconf 2.70 to have the value 'old'; but packages may redefine it to contain 'sane' to impact how AC_PROG_CC_C_O will behave if called without arguments. A future version of autoconf may switch this macro to have the value 'sane'. ============== Usage wise, a configure.ac that uses AC_PROG_CC_C_O([old]) will always have old semantics, regardless of which autoconf version it is built with. A configure.ac that uses AC_PROG_CC_C_O without arguments (most existing scripts) will default to old semantics under older automake; but Automake 1.14 can do 'm4_define([AC_PROG_CC_C_O_MODE], [sane])' at initialization time, to take advantage of sane semantics. Implementation-wise, it would look something like this in autoconf 2.70 (rough draft): m4_define([AC_PROG_CC_C_O_MODE], [old]) m4_defun([AC_PROG_CC_C_O], [m4_if(m4_default([$1], [m4_default(AC_PROG_CC_C_O_MODE, [old])]), [old], [old semantics], [new semantics])]) or, if we wanted to reject invalid input (rather than silently treating all strings != 'old' as 'sane'): m4_define([AC_PROG_CC_C_O_MODE], [old]) m4_defun([AC_PROG_CC_C_O], [m4_case(m4_default([$1], [m4_default(AC_PROG_CC_C_O_MODE, [old])]), [old], [old semantics], [sane], [new semantics], [m4_fatal([unrecognized mode: $1])])]) Either way, you need only switch one line in a future autoconf to default to new semantics. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature