On 01/13/2013 09:01 PM, Nick Bowler wrote: > On 2013-01-12 11:05 +0100, Stefano Lattarini wrote: >> On 01/11/2013 08:16 PM, Stefano Lattarini wrote: >>> On 01/11/2013 07:19 PM, Eric Blake wrote: >>>> On 01/10/2013 06:33 AM, Stefano Lattarini wrote: >>>>> Reference: >>>>> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#50> >>>>> >>>> >>>>> @acindex AC_PROG_CC_C_O >>>>> -This is like @code{AC_PROG_CC_C_O}, but it generates its results in >>>>> -the manner required by Automake. You must use this instead of >>>>> -@code{AC_PROG_CC_C_O} when you need this functionality, that is, when >>>>> -using per-target flags or subdir-objects with C sources. >>>>> +This is an @emph{obsolete wrapper} around @code{AC_PROG_CC_C_O}. New >>>>> +code needs not to use this macro. It might be deprecated and >>>> >>>> s/needs not to/needs not/ >>>> >>> Fixed, thanks. I will soon merge the patch into maint. >>> >> Done. Also merged maint into master, and pushed. > > Hm, so much for waiting a week to push... > No harm done. We already have simplest and sanest semantics than before (which is good). If you patches make that even simpler and saner, we can only rejoice :-). That said, it would be really nice if you could you rebase your changes on current maint (not master), and adjust the commit messages to match.
> This all seems like needless complexity. > I didn't particularly care, since most of that complexity was expected to either disappeared or be moved into Autoconf by the time of the Automake 1.14 release. But if we can remove this complexity *today*, with no loss in functionality and no complication in interfaces, well, I certainly won't complain :-) > It's unclear to me why > my earlier suggestion (using AC_CONFIG_COMMANDS_PRE to expand > AM_PROG_CC_C_O) was inadequate. > Mostly it got lost in the noise, and I didn't consider it carefully enough. Right now, I can't think of any problem with your approach. So, unless somebody else objects or points out possible issues, I believe that would be a better approach than mine. > This would also require no changes to autoconf, and we would not > need to deprecate AM_PROG_CC_C_O, > JFTR, we don't need to do so with my patch either. AM_PROG_CC_C_O is simply a no-op now. Which I believe is good (see also my reply to your second patch for more considerations about this). > so no backwards compatibility hacks are required. > They already aren't required, luckily. > These patches no longer apply to master, > They should go in maint, BTW, since the change is to appear in Automake 1.13.2. > but here they are anyway. > > Nick Bowler (2): > Use AC_DEFUN_ONCE to define AM_PROG_CC_C_O. > Automatically call AM_PROG_CC_C_O as required. > > m4/init.m4 | 5 +++++ > m4/minuso.m4 | 2 +- > 2 files changed, 6 insertions(+), 1 deletion(-) > Thanks, Stefano
