Samba 4 build system (was: Re: Samba3 build farm can't execute smbtorture4 anymore)

[Jelmer Vernooij]

Am Sonntag, den 23.12.2007, 23:01 +0100 schrieb Volker Lendecke:
> On Sun, Dec 23, 2007 at 04:54:34PM -0500, simo wrote:
> > Then the right way is to work out a way to build it statically, it will
> > be useful in general, not fork it out.
> > 
> > > And to be honest, I don't care if smbtorture is structured
> > > nicely, and I don't care about its size. It has to do its
> > > job.
> > 
> > Then fix it, not fork it.
> If Jelmer says he is not able to make the Samba4 build
> system link that statically, I am certainly not.
This is a fundamental flaw in the Samba 4 build system, and not one that
can be easily fixed afaik. 

The current hack (building ldb and its modules as .so's) was enabled to
work around the fact that the build system didn't handle these circular
dependencies. I agree this is not optimal and should be fixed at some
point, although I still don't understand why it is such a huge problem
to rely on shared libs for now, since all the systems we run on support
them and setting LD_LIBRARY_PATH or equivalent is sufficient to use the
shared libraries.

Samba 4 has indeed been the playground of a lot of new things, something
which has been very useful imho. Some things have grown up and
flourished: ldb, tdb transactions, libreplace, pidl, gensec, libnet, the
new server infrastructure, context-based programing and others. Some
have failed: my DCOM code, SWAT2 and the Perl-based ASN1 compiler being
the only I can think of right now that we've pulled for that reason.
Experimentation hinders moving forward to a stable release though, so
focusing on stabilization rather than more experimentation may be useful
(and that probably goes for me more than anyone...). The build system
has been a nice experiment, but perhaps it is another that should belong
in the latter category.

I've done a fair share of work on the build system in Samba 4. The ideas
behind it originally (get rid of the portability code and the redundancy
in the Makefile) were nice, but eventually it's grown into a more
complex beast, almost like a automake clone...  It generates a complex
Makefile from a set of pseudo-makefiles and works on a somewhat higher
level than make but also tends to confuse people unfamiliar with it, and
it's quite tricky to debug when you break it. Abstraction can be a nice
thing because it allows you to work on a higher level, but it can also
be a problem if it hinders you actually doing something properly or
having to resort to weird hacks.

The build system looks like a good example of Not-Invented-Here.
However, about a year ago, I did an inquiry into the various
alternatives that were available at the time and didn't come up with
anything better. Most alternatives either require installing another
application and are too big to include in Samba or don't care about
working on platforms like AIX, Solaris, etc.

And, of course, there's also automake, which has similar problems to the
current build system and relies on recursive make, so I guess that's not
much of an alternative either.

So, the only viable alternative I see to the current build system would
be to go back to something basic - like a autoconf-generated Makefile
from Makefile.in, perhaps distributed across a set of smaller Makefiles
included with "include". It has its flaws, but also certainly its
advantages: it's simple, it's something everybody in the team is
familiar with and it has proven to work relatively well. We can always
reinvent the wheel later...

Thoughts?

Cheers,

Jelmer
-- 
Jelmer Vernooij <jelmer at samba.org> - http://samba.org/~jelmer/
Jabber: jelmer at jabber.fsfe.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.samba.org/archive/samba-technical/attachments/20071224/c779a09c/attachment.bin