Build system (was Re: Future of KDE Development)

Michael Matz matz at kde.org
Mon Feb 21 14:07:18 GMT 2005


Hi,

On Mon, 21 Feb 2005, Stephan Kulow wrote:

> All your complaints are about the process not about the syntax. And this
> discussion is for sure no longer about that the current process is too
> complex - that's for sure.  We're discussing about the syntax -
> highlevel language+everything in one file vs. current syntax+split
> between complex configure tests and simple build description languages.

As you know I'm very fond of Makefile.am syntax.  The easy declarative 
one.  Not the local- targets, and not conditionals.  In fact I'm (like 
Dirk) more fond of an extremely restrictive syntax for the build 
description, not so much of the actual Makefile.am syntax itself (although 
I do like it).

I think such restrictive syntax can also be implemented in scons, if we 
implement enough convenience wrappers for this (e.g. a function for 
declaring (!) each of a program/library/plugin/whatever plus sources), and 
standardize on those (and only those, to make it possible for IDEs to 
parse them).  OTOH, if we do this we could also stay with Makefile.am 
(restricted in some aspects, elaborated in others (like now)).

That's the build description, and I think that's the easy (although more 
interesting to implement) part anyway.

The other thing is the autoconf replacement, and I think that will be more 
difficult.  I would prefer an approach where the configure equivalents 
would still be syntactically separate from the build description 
(obviously there must be a mean of them to communicate, in auto* it's 
Makefile variables, in scons it's the environments).  I don't care if they 
would be run/interpreted by the same process which does the actual build 
(like scons) or not (like configure+unsermake), but syntactic separation 
is necessary I think, also to counter Dirk fears of exploding featuritis 
in the normal build description files, which I have too.

Note that all the above does not rule out scons yet (although I would hate 
to see unsermake die, it has some nice features ;-) ), but it certainly 
needsa good deal of massaging.  But that's true for everything which 
should replace autoconf, which is the real issue we discuss about.  The 
rest is trivial comparatively.


Ciao,
Michael.




More information about the kde-core-devel mailing list