proposal: merge waf build of s4 to master
tridge at samba.org
tridge at samba.org
Wed Apr 7 04:41:14 MDT 2010
> Yes, and that is a problem. That tarball will bit-rot very
> quickly. But if you need it, your *really* need it.
Then we just make some of the build farm hosts build from it. We'll
get an email if it breaks. See the install_python.fns build farm
script I posted a few days ago as a proof of concept.
> True. But not all of them. Why should we break existing
> setups with no good benefit for the end-user?
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
> 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?
> 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!
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.
> Sure, but this does not really say much about the way the
> split out component is being built. Why does it have to be
> one single build system for all of Samba?
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
> This is not the point. It is just silly from my point of
> view not to use and incrementally improve what we have. The
> current build system works for Samba3, and you have not
> given me enough benefits our end-users will have when we
> throw away the current system.
Once Kai has done the s3 build, then please do him the courtesy of
trying it. Maybe you'll be surprised and you'll find you actually like
Until he's done it, we're discussing vaporware. It can be hard to see
the benefits of something you can't try.
More information about the samba-technical