proposal: merge waf build of s4 to master

[Andrew Bartlett]

Volker,

On Tue, 2010-04-06 at 07:35 +0200, Volker Lendecke wrote:
> In this thread I have tried to find out the real advantage
> that the end-user of Samba has from waf. Tridge has named a
> few, most of which are also possible in a autoconf based
> system. The colored progress bar might be a challenge, but
> I'd call that dispensable.

While Tridge has listed some advantages, and has done the work to
implement some new and I hope useful behaviours, I think you are
applying the wrong standard.  Our users should not care what build
system we use, as long as it works for them - therefore the standard for
them should be 'is this new build system acceptable'. 

Similarly, for your use case, and for your position as a developer, I
can't seen any immediate advantages either.  You know and understand m4,
make and shell well, are comfortable with the current system, and are
rightly focussed on maintaining the Samba3 code, particularly for your
customers.  Any change only increases your burden. 

> To be honest, so far I have not been convinced to throw away
> the old system in favor of something that will bring its own
> set of problems. The current system might be verbose and
> clumsy to use, but it is understandable. For example the GNU
> ld detection problem with SLES 11 that I recently fixed was
> pretty simple to do. I am sure that you will reply this
> particular one is just no issue at all with waf, but when
> some similar problem appears with waf, I know that I will be
> very pissed when I have to wade through hundreds of lines of
> python code to find the place where it fails. You might say
> that we have good contact to the waf author, but what
> happens when he is on vacation for a month? The autoconf
> based system has tons of independent documentation and the
> resulting configure is a pure shell script without much
> magic. To me this is an advantage that is very hard to beat
> when you want to fix things.

While I would challenge the notion that any system based on m4 is
'understandable', this is a very real risk we have to take on as a team.

Tridge and others have become quite familiar with the waf system, and I
certainly would prefer to debug python compared with m4 generated files.
But I still have to say this is a very real risk, and one that we have
to decide to take on as a team. 

But these risks also come with benefits.  I was similarly questioned
when I chose to have Samba4 take on Heimdal Kerberos, which is likewise
largely a one-man project.  This has turned out to be a great success
for Samba4.

While I would not have chosen to change the build system right now,
tridge has shown that Samba4 needs a new build system, and I think we
need a better build system for the merged build.  Many have rightly
argued that the current situation is unacceptable.  It is a marvel that
it even works, but for Samba to advance to the merged codebase of the
'Samba 4.0' release we have promised, we also need a common build
system.  

We need to be able to reliably and reproducibly build any part of Samba,
without distinction as to what branch it is or was part of, with simple
typos spotted and with our project rules checked every time. 

There should not be different build rules for the same .c file, nor two
different ways to build libraries such as pam_winbind.so. Someone
extending a shared component should not have to learn two different
build systems, just to add a file. 

We should be able to test Samba3 against Samba4 as an AD domain
controller every time we run 'make test', and we should ensure that
common code works in both branches, every time. 

That is why, *when* Kai is finished doing his conversion, I hope you and
the rest of team will support Samba3 also using waf, firstly as a
secondary system, and eventually the primary build system.  In the mean
time, we are trying to decide if Samba4 can accept waf into the tree, as
a secondary system. 


I'm sorry this feels forced on you.  Aside from 'no change', what would
you do differently?  

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100406/01b189bf/attachment.pgp>