Reduce build systems in master

[simo]

On Mon, 2011-09-05 at 21:44 -0700, Jeremy Allison wrote:
> On Mon, Sep 05, 2011 at 03:45:08PM +1000, Andrew Bartlett wrote:
> > On Thu, 2011-09-01 at 15:13 +1000, Andrew Bartlett wrote:
> > > Following up from my mail last month, attached is my proposal to reduce
> > > the build systems we need to maintain to two, the top level waf build
> > > and the autoconf build.
> > > 
> > > The s3-waf build has been incredibly important in getting us this far,
> > > but I don't we should continue to maintain three build systems now that
> > > the top level build provides all the functionality we need.
> > 
> > I would like to put these patches into the tree this week.
> > 
> > To reiterate, the reasons I want to do this are:
> >  - So we reduce the number of build environments we all have to support
> >  - To avoid maintaining build environments that do not help us release
> > our next major release, the combined Samba 4.0.
> >  - 'make test' in the s3-waf build does not even start, so clearly this
> > build is untested
> >  - The s3-waf build has a large number of duplicate symbols (make
> > SYMBOLCHECK=1)
> >    - These could possibly be resolved 'easily', but the list of
> > duplicates appears just as long as it was when I last raised the issue
> > 
> > The bigger background to this desire is that I've been working hard to
> > bring us closer to being one project, and I want to allow all parts of
> > the tree to link to any library, restricted only by what that library
> > itself depends on and it's suitability for the task, not that where it
> > is located in the tree.
> > 
> > This is of course constrained by the need to maintain the autoconf build
> > in the short term, but I would prefer not to have the s3-waf build
> > additionally restricting our development opportunities.
> > 
> > I have maintained the krb5 library checks, to allow a future developer
> > to conditionally permit the whole Samba 4.0 release to compile using a
> > non-Heimdal system Kerberos if they have the time to re-implement the
> > required features.  (The challenge is in the detail, the broad
> > functional APIs have converged a lot in the past years). 
> 
> Ok, there's only one thing I need to check - does this
> remove the ability of vendors who want to ship file server-only
> Samba4.0 products to use existing MIT krb5 libraries ?
> 
> That would be a big problem for several OEMs I know.
> 
> If it means a complete top-level build uses the included
> Heimdal code that's fine, but not if it forces embedded
> systems to do so under all circumstances.
> 
> If I'm reading you correctly the solution for doing this is use
> the old autobuild system to do this ? If so that's fine too. I
> just need to know there's at least some way to do this.

It's not ok for me.

I need a few samba4 libs already and I need to use MIT.

So I need to build as mush as I can of the code without having to use
the embedded KDC or heimdal libraries.

I can put people at work to achieve this if necessary but I need the
collaboration of the samba4 DC people to make this possible.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>