[PROPOSAL] To retire autoconf for 4.1

Volker Lendecke Volker.Lendecke at SerNet.DE
Wed May 22 23:26:44 MDT 2013


On Thu, May 23, 2013 at 07:49:01AM +1000, Andrew Bartlett wrote:
> On Wed, 2013-05-22 at 10:21 -0700, Matthieu Patou wrote:
> 
> > As I pointed on IRC, we should reduce the number of groups so that 
> > linking can kick up while some stuff are still compiling (if possible) 
> > and potentially not do the symbol checks if we have specified --targets= 
> > on the command line so that we don't force to rebuild every thing that 
> > depends on this change.
> 
> The duplicate symbol checker is run on make test, not on make for this
> reason. 
> 
> The --symbol-check option is not enabled by default, nor is it turned on
> by --enable-developer. 
> 
> The ABI checker can be disabled by configuring with --abi-check-disable,
> and as I understand the code only runs on libraries that have been
> changed or re-linked.  That said, I do agree that waf tends to prefer to
> re-link over being sure that it doesn't need to. 
> 
> > This should make the speed of waf build --targets=smbtorture much faster 
> > when you change something in talloc.c or whatsoever.
> 
> One of the key reasons to make this change is so that if we can find
> ways to make waf both totally reliable and a bit faster for developers,
> that we have those resources, rather than also spending those on
> maintaining a parallel build system.  
> 
> It is however really important that our build systems are totally
> reliable.  It is no benefit being a bit faster building if we loose that
> time again debugging an 'impossible' Samba crash, that doesn't reproduce
> anywhere but the customer's production environment, because they patched
> Samba and didn't rebuild from 'git clean -x -f -d' or a fresh tarball
> checkout.  

Our perception might just differ here. I do get those
crashes, yes, but for me they are very rare. Not more than
once or twice a year. And yes, if I get them, it takes me a
couple of minutes to realize I should retry with a clean
build. These few minutes for me are nothing compared to the
wait time for every single build.

> The fact that waf always builds correctly, without special rules is a
> key feature that *saves* developer time in the long run, by ensuring
> that our users (who overall, build samba even more than we do) always
> get a correct build. 

I'm not sure about that. The people who track us with a git
pull should know that a git clean -dxf every now and then
helps. Has this imprecision really caused us so much trouble
before waf came along that we want to put delays on
everybody who writes code every day? The clean build that
our users build from (get the tar, unpack it and build) has
worked pretty well so far.

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de


More information about the samba-technical mailing list