Reduce build systems in master

Jeremy Allison jra at samba.org
Mon Sep 5 22:44:58 MDT 2011


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.

Jeremy.


More information about the samba-technical mailing list