Build system (was Re: Future of KDE Development)

[David Faure]

On Friday 18 February 2005 16:26, Stephan Kulow wrote:
> cons: 
>  - we spent time hacking the build system instead our code
I'm surprised you're not defending more your investment: given that I doubt scons
has all of unsermake features, we'll have to hack scons if we want to keep
those features. But of course scon's scope is bigger than KDE so there are
other people working on it.

>  - it wouldn't solve one major problem David forgot in his list of problems
>    with current method: the lack of consistent documentation. We have 
>    a HOWTO, but it surely doesn't cover everything needed.
> 
> As long as no-one seriously steps up and says he would document our
> extensions, I see scons extensions as better alternative. 

You mean for Makefile.am syntax? I do step up and offer to document whatever
is not yet documented in the Makefile.am howto (what do you have in mind, for instance?).
[If we keep Makefile.ams for KDE4, that is].

> And I kind of like 
> the aspect of having full power in the Makefile/SconsFile - e.g. compare
> 
> configure.in.in:
> AM_CONDITIONAL(include_BLAH, [test -x `which blah 2>/dev/null`])
That part would be different if using python-based configure scripts instead of m4/autoconf.

> Makefile.am
> if include_BLAH
> bin_PROGRAMS += blah_addon
> blah_addon_SOURCES = addon1.cpp
> ....
> endif
Yep. Simple and easy to parse :)

> with
> 
> SconsFile:
> if kdeenv.findProg("blah"):
> 	kdeenv.compileAndInstallProgram("blah", "addon1.cpp", install=kdeenv.bindir)
Powerful, but as Harri points out, too powerful for IDEs.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).