Samba 4 build system - more thoughts on scons

[Jelmer Vernooij]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tridge,

tridge at samba.org wrote:

>> Changing the configure stuff over later would be a good idea. I
>> was initially planning on doing it all at once, but I guess
>> you're right in that we could leave some of the nasty bits (such
>> as the developer flags) in the configure script for now.
>
> If we are going to start using scons and it can replace configure
> then I'd rather switch over completely rather than using a mix.

I agree that we should switch over completely to scons, though we can
actually use some of the autoconf-found data in scons while we don't
have some of the M4 macros in scons yet. It's very useful to be able
to run scons now without having to port over all configure tests first.

> We already have a mix of perl, m4 and shell, to move to a mix of
> python, perl, m4 and shell doesn't seem like a step in the right
> direction to me. Unfortunately this means rewriting an awful lot of
> existing m4 tests, some of which are quite intricate. So we better
> be very sure that scons is the right way to go! I have no
> experience with it myself.

What I'm proposing as would be python-only (generating pure-shell
configure and Makefile). This would be a general-purpose solution for
scons, nothing Samba-specific.

>
> We also need to make sure that scons can really do all the things
> we need. For example we need:
>
> - an equivalent of the --some-option=blah stuff from autoconf

Yep, it can certainly do that.

>
> - a way to have different CFLAGS in different directories (the
> equivalent of extra_cflags.txt that we have now)

We're already doing this in some of the test stuff (for example,
dynconfig.c is the only file compiled with the -DBINDIR=..
- -DSBINDIR=... etc flags)

>
> - keep the build information about a directory in that directory,
> while not using a recursive build

Does that as well. Nice thing is that a directory can also easily
stand on it's own (useful for ldb / tdb / talloc )

>
> - lots of autoconf tests for all of our HAVE_* and REPLACE_*
> defines

the autoconf-alike part of

>
> Are you confident that its going to be worthwhile to switch over?

Yes, I am very much convinced scons is the way to go. It provides all
that we need (see my original email for details).

I'm currently just playing around with it for the moment, trying to
see if I can get it working a bit; I hope I didn't give the impression
I was trying to force scons down everyone's throat :-). Once we get
some core things working, we could (if we ever get to that point
without running into major issues) decide on whether to go ahead with
scons. In what I've seen and experienced so far scons is far superior
then our current build system, but we'll see :-)

If it helps indicating the capabilities of scons: KDE is now also
slowly switching some of their applications (most notably the core
kdelibs) to scons.

I hope to have something working ready within a week or so.

Cheers,

Jelmer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDL0sIPa9Uoh7vUnYRAi/GAJ4npQOaodTKnVj/N2X3UGkhNbkCpQCfbPHi
dwRJupBessoQyqkK3zfLur8=
=fYy3
-----END PGP SIGNATURE-----