Build system (was Re: Future of KDE Development)

[Stephan Kulow]

Am Friday 18 February 2005 16:51 schrieb 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
If scons were perl I would surely protest, but it's a logical step for me. But as I said
earlier, I haven't actually looked at scons, so it might be well possible that it turns
out to be much worse than hacking unsermake.

> 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.
You name it. My plan is to start with the configure part rewrite with having scons
in the backhead. And if we have that (which we need in any case), we see what
needs to be done to go in either direction.

> 
> >  - 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].
Well, it's not just about a Makefile.am howto. It's about changing the build system
if it doesn't work. The automake info pages document a lot of what's bound to configure.
If we're going to change the configure part drastically, we have to extend that a lot.

> 
> > 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.
Sure, that wasn't the point - the point was more to have it in two files.

> > SconsFile:
> > if kdeenv.findProg("blah"):
> > 	kdeenv.compileAndInstallProgram("blah", "addon1.cpp", install=kdeenv.bindir)
> Powerful, but as Harri points out, too powerful for IDEs.
> 
Hmm. Is this our major concern? kdevelop can parse, complete and write C++ after all ;)
But if this is indeed one of our concerns, then staying with simple Makefile.ams is indeed
a good alternative. And I have myself no problem with Makefile.ams either, but I understood
the kde-devel thread, that many others do have. 

But finally the discussion opens in a way I wanted it: people are actually express what they
want from the build system. 

Greetings, Stephan