proposal: merge waf build of s4 to master

[Volker Lendecke]

On Wed, Apr 07, 2010 at 07:59:12PM +1000, tridge at samba.org wrote:
> It would have a convenient script to install it within the Samba build
> tree. I would expect that we'll find very few downloads of Samba will
> be of the -with-python tarball, as pretty much everyone has it these
> days. There will be some, but it will be a tiny proportion of all
> downloads.

Yes, and that is a problem. That tarball will bit-rot very
quickly. But if you need it, your *really* need it.

> The vast majority of people who are building and installing Samba
> won't need this. Even you won't need it for the vast majority of your
> work on Samba. 

True. But not all of them. Why should we break existing
setups with no good benefit for the end-user?

>  > How does the build system affect sharing code?
> 
> Please see my previous answer to this.
> 
> The "we should componetise" argument that you answered with doesn't
> address the QA problems. We have quite often had problems where
> someone makes a chance for s3 that breaks s4 and vice-versa. 

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. If we arbitrarily change
APIs and ABIs just at will then yes, sure, these kinds of
problems will arise.

> We will save a lot of these headaches if the common components always
> build in the same way, and if we reach the goal that Metze has
> outlined, which is that Samba developers build in the top level and
> always end up building both branches every time.

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?

> You spending a few extra seconds downloading 11M for one or two of
> your customers is a pretty trivial price to pay for these types of
> gains. You can charge them for the bandwidth if you have to.

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.

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/ebb2f4bb/attachment.pgp>