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