Samba 4 build system - more thoughts on scons

[Jelmer Vernooij]

On Mon, Sep 19, 2005 at 09:59:19PM -0500, Albert Chin wrote about 'Re: Samba 4 build system - more thoughts on scons':
> On Sat, Sep 17, 2005 at 09:00:56PM +0200, Jelmer Vernooij wrote:
> > 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.
> So are the various technologies wrong or how they are mixed
> together/used?
- autoconf (a set of m4 macros combined with inline shell code)
generates shell code (configure)
- autoheader (a perl script) generates include/config.h.in
- configure (generated above) replaces variables in Makefile.in and
  config.h.in

The Makefile is hand-written but has to keep in mind various
incompatibilities between different versions of make. It also depends
on several shell scripts to help here. Furthermore, one has to repeat 
the same patterns over and over again.

Configure scripts can get very large - making debugging errors in them
hard. 

There are all good (historic) reasons for this, as autoconf evolved
from a simple shell script into what it is now, but it does make it a
complicated beast.

> > - - generates large amount of data (800kb configure script!) that needs
> > to be in the tarball
> Disk is cheap. If autoconf makes a package easy to build and the
> configure script is big, fine by me.
Autoconf is not the only thing that can make a package easy to build
and configure.

> > - - incompatibilities between various versions of make
> Require GNU make.
That would probably mean losing half of the hosts in our buildfarm,
and (thus) reduce portability. My main concern with using scons is its
dependency on python - depending on gmake is even worse.

> > - - slow
> How about using config.cache? Or config.site? For someone building
> Samba once, a slow ./configure isn't a big deal.
For development, it can be annoying. 

> > - - portability layer and build data thrown together
> You mean in a single config.h file? You can have multiple like the
> Glib folks do but you need to manually generate other "config.h"
> files.
No, the fact that the Makefile contains a lot of CC-specific hacks but
also contains the lists of files that need to be in a certain binary,
etc.

> > - - duplicated work (other projects need to have the same tests, code)
> Splitting the tests to separate .m4 files solves part of it.
True, but that doesn't happen much. Most of the tests other projects
use depend on automake in some way (which we don't use at all).

> > - - cross-compilation hard to get right (we currently have it, but the
> > HOSTCC code is rather hackish)
> How many people use cross-compilation to justify spending time on it?
We are currently trying to get Samba to compile with mingw32. scons
would probably allow it to compile natively on windows (with MSVC)
without any changes. Cross-compilation is also important to people
that want to compile for embedded platforms.

> > 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:

> > [ requirements snipped ]
> am-utils runs on a very large number of systems. autoconf works for
> them.
Sure, but that doesn't mean those are the only build utilities that
are portable. If there's something that can do better, why not try it?

> Keep in mind the people that will be _building_ samba (users,
> distributors). They're all familiar with autoconf.
Samba4 doesn't use plain autoconf at the moment - it uses a custom
system, combined with some autoconf and autoheader. scons is at least
more commonly used then the current build system (for example, kdelibs
uses it now)

> Also, if you switch, it should be possible to specify the following:
>   CC=[custom C compiler, probably from the vendor] \
>   CFLAGS=[custom C flags] \
>   CPPFLAGS=[-I paths to search for readline, OpenLDAP, etc.] \
>   LDFLAGS=[-L paths to search for readline, OpenLDAP, etc., and
>            flags like -R to embed the runtime path of these
>            3rd-party libraries]
scons supports all this.

> We build tons of freeware on various systems. I dislike every build
> system except for autoconf. But, I'm looking at it from the viewpoint
> of an end-user who _builds_ software, not develops it.
Just because its what people know doesn't mean it is better.. that
means you'd be stuck with the same tools forever. Of course I'm
concerned about not alienating users because of this, but there are
ways of making the transition easier such as providing a dummy Makefile that 
calls out to scons.

Cheers,

Jelmer

-- 
Jelmer Vernooij <jelmer at samba.org> - http://jelmer.vernstok.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20050921/f060e987/attachment.bin