A DRAFT statement on our build systems for Samba 4.0
Andrew Bartlett
abartlet at samba.org
Thu May 17 07:40:04 MDT 2012
On Thu, 2012-05-17 at 09:29 -0400, simo wrote:
> On Thu, 2012-05-17 at 23:27 +1000, Andrew Bartlett wrote:
> > On Thu, 2012-05-17 at 09:12 -0400, simo wrote:
> > > On Thu, 2012-05-17 at 17:43 +1000, Andrew Bartlett wrote:
> > > > >
> > > > > I'm trying to make it clear in our user's minds that we have moved
> > > > past
> > > > > having a 'file server' build and an 'AD build', and that for almost
> > > > all
> > > > > users, the top level build is the one they want.
> > >
> > > Do we have a toplevel waf switch to build only the file server (+nmbd
> > > +optionally winbindd) and not the whole AD DC stuff ?
> >
> > Not at the moment.
> >
> > Skipping the new binaries shouldn't be hard, but skipping the libraries
> > only then depend on will be a little trickier.
> >
> > If possible I would prefer to avoid having to mark every subsystem as to
> > being a 'file server only' or 'full Samba 4.0', but if we cannot
> > automate it, I guess this can be done.
> >
> > We should however not box ourselves in - it should be a tool to avoid
> > installation of unused code only, not another dividing line between
> > parts of the codebase.
>
> My aim is to simply be able to tailor the build to the parts a user
> really want to use, for example I wold like a --without-spoolss at some
> point, and tat would stop building printing code.
Would it be better to allow it to be a module, and then just not package
the printing code?
The issue with not building it is that 'make test' would need to be told
about each thing being omitted, so as to skip some tests. We could make
it conflict with --enable-sefltest, but then un-testable combinations
are not great either.
While everything is possible in software, the combinational complexity
and the need to actively verify the result here worries me. (As
background, I've already been contemplating how we can ensure that at
least some tests are still run with your waf MIT krb5 build).
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical
mailing list