Build system (was Re: Future of KDE Development)

[Stephan Kulow]

Am Friday 18 February 2005 15:42 schrieb Oswald Buddenhagen:
> On Fri, Feb 18, 2005 at 03:32:14PM +0100, David Faure wrote:
> > How about we keep Makefile.am, but use unsermake (as a dependency,
> > which has to be installed first - no admin/ copies; oh, and with a better
> > name of course). And for the configure part, using something like what
> > scons provides - so that it's python all the way through.
> > python can't be more scary than m4/autoconf macros, and for simple 
> > things we can simply write a Makefile.am, as always.
> > 
> i love this idea.
... which scares me in return ;)

The aspect of keeping unsermake as build tool is two fold: 

pro: 
 - we can keep the Makefile.am syntax our developers are used to
 - we can even add syntactic sugar where it's felt as needed 

cons: 
 - we spent time hacking the build system instead our code
    [ok, we will spent time hacking scons extensions too, but very likely
     less time]
 - 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. 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`])
Makefile.am
if include_BLAH
bin_PROGRAMS += blah_addon
blah_addon_SOURCES = addon1.cpp
....
endif

with

SconsFile:
if kdeenv.findProg("blah"):
	kdeenv.compileAndInstallProgram("blah", "addon1.cpp", install=kdeenv.bindir)

(I made up that syntax, I only had a very brief look at scons so far).

Greetings, Stephan