Samba 4 build system - more thoughts on scons

[James Peach]

On Sat, 2005-09-17 at 21:00 +0200, Jelmer Vernooij wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> The Samba 4 build system is getting more and more enhanced. We
> originally started out with a traditional autoconf system. I.e. we
> generated a configure script from configure.in that then substituted
> several values in Makefile.in.
> 
> Metze and I have gradually been changing this to an autogenerated
> Makefile. We just abandoned the templating mechanism and are now
> generating the Makefile directly from the data gathered by configure
> and various .mk file in the source tree. Perhaps we'll eventually end
> up with a perl-based configure. We could of course continue on this
> road and reinvent the wheel , but I'd rather use some other solution
> instead - that would save us some time and the pain of maintainance.
> 
> The problems with the combination of autoconf and make are:
> - - hard to write (various technologies thrown together). Writing M4
> that generates shell scripts that generate perl code that generates
> Makefiles is not really the ideal way of working.
> - - generates large amount of data (800kb configure script!) that needs
> to be in the tarball
> - - incompatibilities between various versions of make
> - - slow
> - - portability layer and build data thrown together
> - - duplicated work (other projects need to have the same tests, code)
> - - cross-compilation hard to get right (we currently have it, but the
> HOSTCC code is rather hackish)

The two main problems I have with the current Samba 4 build system is
that it is both complex and non-standard. The usual autoconf/automake
system is complex, but at least it is well known and generally well
understood.

> Several alternatives are available - most of which integrate the
> configure and build stages. However, we have a large number of
> requirements for our build system:
> 
> - - distinction between different targets of compilers (build / host)
> - - ability to build certain subsystems stand-alone
> - - generate pkg-config files for libs
> - - it must support custom file types that can be compiled (IDL, asn1,
> heimdal et, SWIG, etc)
> - - must run on exotic UNIX systems (AIX, IRIX, CrayOS, etc)
> - - no external dependencies (e.g. not requiring the installation of
> python) in order to build. We consider cc, make and perl valid
> requirements for building.
> - - optional init function per subsystem that must automatically on
> binary startup
> - - support for automatic header dependencies (header changes, all files
> that use it get recompiled too)
> 
> These are pretty heavy requirements. Probably one of the only
> applications that I could fine that provides all these requirements is
> <a href="http://www.scons.org/">scons</a>. It is small enough to
> include in the source tree, but unfortunately depends on python.
> 
> We discussed scons earlier and then didn't look at it further because
> it was in python, but I'm a bit more convinced we need something like
> scons rather then the complicated setup we have now.

I would generally support using something like scons on the basis that
is it a system that is maintained and documented by some one else. I
don't have any problem with requiring python provided there is a
commitment to support the relatively old versions on python running on
the more exotic platforms.

> One of the ways of solving this could be writing a python script that
> generates a configure script and Makefile.in that can then be used on
> hosts that do not have python installed. This would be a bit similar
> to the 'autogen.sh' script we have currently. I'm not sure how
> feasible writing such a script is yet, but I'll be looking at writing
> one during the next few days.

I don't think there is any value in developing a samba-specific build
system. Frankly, I think we would all rather be working on Samba than on
the build system. I would support requiring scons or GNU Make, but I
don't see the point in simply rewriting what we have today in python (is
that what you are suggesting here?).

-- 
James Peach | jpeach at samba.org