Reduce build systems in master
idra at samba.org
Tue Sep 6 13:07:55 MDT 2011
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.
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>
More information about the samba-technical