Subject: bug#20082: new warning from ar on rawhide systems

From: Eric Blake <[email-masked]>
Date: Fri, 27 Mar 2015 10:51:36 -0600

On 03/27/2015 09:48 AM, Pavel Raiskup wrote:

> So probably the worst slowdown would be an 'ar' task to update archive
> consisting of a big amount of small files when only one has changed.
> 
> FTR, Automake uses 'cru' since at least ~1994 initial commit in git, cmake
> uses 'cr' only.
> 
>> And of course there's the question of how easy is it to detect that ar
>> is new enough to understand the 'D'/'U' dichotomy?
> 
> Not sure.  Probably ./configure check like '--version works' && 'GNU in
> --version' && 'ar crD' could be enough..

Hmm. How hard is it to change ARFLAGS to 'cr' instead of the default of
'cru', so that projects that want to silence the warning now can do so
without waiting on automake to catch up?  (Remember, the warning is live
on rawhide systems now, and even if we release a new automake with a
patch to change the default, there are TONS of packages built with older
automake that will still warn until such time as autoreconf is run on
those packages to update them to the newer automake)

> 
> However, having best-effort determinism in Automake does not guarantee
> determinism of final result..  Is it worth the trouble?  I could imagine
> some general './configure --enable-deterministic-build', but then I would
> expect the configure to fail if the 'D' option is not available..
> 
> Having used 'cru' with optional 'cruU' could have at least a small benefit
> that the default behavior would behave consistently at least on boxes
> running GNU ar..  which is not the actual state.

So you are arguing that 'crD' is smarter than 'cruU' if we bother to
detect new enough binutils, but that 'cr' is just about as effective and
then we don't have to worry about the detection at all.  And if I
understand correctly, the warning occurs if we use just 'cru' but the
binutils defaulted to 'D' (rather amusing, that 'cruD' is the spelling
that warns).

Next step - how to patch automake.  I'm not familiar enough with the
internals to quickly find the location to patch, if someone else is able
to do it quickly.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org