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