proposal: merge waf build of s4 to master

Volker Lendecke Volker.Lendecke at SerNet.DE
Tue Apr 6 02:27:22 MDT 2010

On Tue, Apr 06, 2010 at 06:07:48PM +1000, Andrew Bartlett wrote:

> 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'. 

True, but I fear that it does not work for them due to the
python dependency in a non-zero amount of cases. And these
cases at least to me tend to be important ones. This is not
only driven by SerNet's business interest, don't get me
wrong here. A high-profile AIX case that can be solved for
free via bugzilla is also very interesting to me. I just
mentioned SerNet because I see more of those rare platforms
due to our customers.

> 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.  

As an alternative, we might go and componentize stronger. In
Samba3 we have put in the ability to use external RPC
servers for example. libwbclient abstracts away winbind, so
it should be possible to use a 3.5 winbind with a 3.4 smbd.

As a default, I stronly argue to have one ./configure;make
do everything, but I doubt that forcing the same build
system on everything is technically required. It might be
more effort to keep two systems, but it also forces us to
more strongly focus on the interfaces between our
components. And this is something that can only benefit

> 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 Someone
> extending a shared component should not have to learn two different
> build systems, just to add a file. 

If we had good interfaces and separated components, it would
be completely unnecessary to build things like pam_winbind
differently. It should be an independent component or
sub-project that can make its own decision for a build

> 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 don't think I objected to converting the pure Samba4 build
to waf. If you find a mail where I did so, I hereby
apologize for it.

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

As I have stated in previous mail, for the pure Samba3 build
I do not see the need for a change. I just don't see the
value of throwing away a build system that works fine for
our end users.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <>

More information about the samba-technical mailing list