[devel] Fw: Re: Samba 4 build system - more thoughts on scons

[Alexander Bokovoy <ab@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 2855 bytes --]

Результаты экспериментов со Scons в Samba 4:

----- Forwarded message from Jelmer Vernooij <jelmer@samba.org> -----

Date: Thu, 20 Oct 2005 00:18:52 +0200
From: Jelmer Vernooij 
Subject: Re: Samba 4 build system - more thoughts on scons

Jelmer Vernooij wrote:
> While I was very positive about scons a month ago, I must admit that
> enthusiasm has faded a bit now that we tried out to use it for building
> Samba4. The idea behind it is good, but there are some issues when using
> it in real life (some of these I knew about before I started or were
> predicted by others):
> 
> - It assumes the relations between subsystems are compositional. If dir
> a is processed before dir b, dir a can not depend on any object files
> from dir b. This is a major problem for Samba.
> - Running the configure tests (even with caching) each time you run a
> build takes way too much time for a project with as much tests as Samba
> (althought there are hacks around it).
> - No easy way to add configure test functions
> - Python
> - Slow. Calculating checksums for each file rather then relying on
> modification times may be nice for those that have their sources on NFS,
> but it slows scons down a lot.
> - Very much focussed on files and conversions between files - generating
> a list of init functions like we do at the moment is quite hard.
> - While in theory it should be possible to generate a configure script
> and Makefile.in from a set of SConscript files, this proved to be a bit
> harder then I'd hoped.
> 
> Of course, it's not all bad. Some good things about scons:
> - Can transparently handle portability issues with different compilers,
> architectures
> - The support for multiple build types is very neat and useful
> - Automatic support for header dependencies
> - Easy to extend. Scanning for dependencies, adding file types, adding
> compilers is trivial.
> - Compositional to a high extend. Being able to put the list of files
> and the list of functions/headers a subsystem needs in one file in that
> subsystems dir is very useful.
> - Configure scripts and tests are much easier to read
Summarizing this whole story a bit, I guess I could say that scons is
the perfect tool for small projects.

It doesn't scale well though in terms of build items and configure
tests. It also lacks support or flexibility for the special features
larger projects need - in the case of Samba the init functions,
optionally disabling subsystems and the subsystems that depend on them,
deciding between object lists and shared libraries.

Cheers,

Jelmer

----- End forwarded message -----

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]