From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 20 Oct 2005 09:03:28 -0400 From: Alexander Bokovoy To: devel@altlinux.org Message-ID: <20051020130328.GA24547@altlinux.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline Cc: Subject: [devel] Fw: Re: Samba 4 build system - more thoughts on scons X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2005 13:04:14 -0000 Archived-At: List-Archive: List-Post: --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =F2=C5=DA=D5=CC=D8=D4=C1=D4=D9 =DC=CB=D3=D0=C5=D2=C9=CD=C5=CE=D4=CF=D7 =D3= =CF Scons =D7 Samba 4: ----- Forwarded message from Jelmer Vernooij ----- Date: Thu, 20 Oct 2005 00:18:52 +0200 =46rom: Jelmer Vernooij=20 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): >=20 > - 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. >=20 > 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 ----- --=20 / Alexander Bokovoy Samba Team http://www.samba.org/ ALT Linux Team http://www.altlinux.org/ Midgard Project Ry http://www.midgard-project.org/ --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDV5WgncWKdrYPwpkRAngtAKCx7WjEdnEHaqsmTQJApAVK/pNjNQCfXe9l qk8csnM++w7HHwQwMNrUD44= =uxc1 -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9--