proposal: merge waf build of s4 to master

[Volker Lendecke]

On Wed, Apr 07, 2010 at 08:41:14PM +1000, tridge at samba.org wrote:
> The benefit to the end user, apart from the ones I posted previously,
> are that the project benefits because the developers are able to get
> on with the job of developing better than they can now. Having a
> better build system saves us from wasting time with broken builds and
> broken dependencies. That helps end users as they end up with a better
> product.

The dependencies in Samba3 are not so complicated that they
can not be dealt with within a autoconf based system.

>  > This is a problem of missing discipline in APIs. The talloc
>  > ABI has been broken recently for (IMHO) no good reason
>  > and/or benefit for our end users.
> 
> The benefit was that we produced better debugging for a very common
> talloc programming error. That improved debugging has led to quite a
> few bug fixes since it went it. That means we now have better code
> than we had previously. Surely that is a worthwhile gain?

Sure, but the long discussions with samjam just taught
everyone that talloc_reference is just a bad idea. The real
fix is to just not use that call.

>  > If we arbitrarily change APIs and ABIs just at will then yes, sure,
>  > these kinds of problems will arise.
> 
> arbitrarily? You're saying I just picked the change on a whim? 
> 
> I made the change as it was the single most common cause of
> programming errors with the talloc API. It was causing very subtle and
> hard to track down bugs that I had personally spent many days trying
> to find. I know that other Samba developers had similarly hit problems
> debugging that type of error, and were getting very frustrated. It
> also caused subtle crashes for our users.
> 
> That whole class of bugs now becomes very easy to find and fix as we
> get really good debug information that tells us not only where the bug
> surfaces, but also the line of code where the original call was that
> caused the problem. All of that at essentially zero run time cost. I
> think it was a bargain!

Well, just don't use talloc_reference.

> Related to this, the problems it has caused with building against
> talloc on some system is precisely because our build system is broken,
> and it is one of the things the waf based build fixes! The old build
> system hardcodes in the use of -Ilib/talloc, because doing anything
> else with the old build system is too hard. That means we use the
> in-tree talloc.h with the system talloc library. That causes breakage.

What blocks us from fixing those problems within the current
autoconf based system?

> It doesn't have to be, but a single build system means it is far more
> likely that a change in one branch will cause build breakage in
> another branch.

If we had well-defined components, they would be built
within their own build system once for both Samba3 and
Samba4.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100407/d55efc96/attachment.pgp>