Build system (was Re: Future of KDE Development)

[Dirk Mueller]

On Saturday 19 February 2005 09:45, Stephan Kulow wrote:

> Just to get this right: when you say "the rest" you mean the syntax not
> the tools, right?

Yes, just the amount of flexibility of our build system syntax. I don't care 
which tools we use to actually build, although I generally think that 
standard tools (automake&autoconf) produce better confidence in our project, 
even though we do know that those tools are crap. unsermake is nice because 
it doesn't try to do something new.. it just tries to be better. and it seems 
it does that increasingly well (even though I still don't use it ;) ). 

I'm afraid that a full scriptable build system will quickly lead to 
unmaintainable structures. For example if we actually have the flexibility to 
work around every little toolchain bug (like "compile x.y on platform z 
crashes if run with a.b"), then we will actually do that, because somebody 
will somewhen provide a patch and it will be committed, because it does the 
thing. Packagers tend to do that, especially SuSE packagers, since it seems 
easier for them to add a hack to their own package than to communicate with 
another person to get the bug in the toolchain package fixed. However, it 
quickly rots and think about 5 years from now if we can add hacks to every 
little short-time problem, then complexity *will* explode.

We had the problem already in the past: For a long time we had funny hacks in 
all our Makefile.am's because the only automake version we supported was 1.4. 
Back then when new versions started to pop up, which were incompatible and 
had even less features than the older versions, we actually started to clean 
things up. unsermake did something similiar: we suddenly had so much more 
possibilities to enforce rules on the structure of our build descriptions. 
And they made things better, because most of our Makefile's now are a lot 
easier to understand than 5 years ago. Its so much harder to add crap to 
makefiles now because somebody will immediately notice: either srcdir!= 
builddir is broken, or am_edit barfs, or automake barfs, or unsermake barfs, 
or it just plain doesn't compile in any of those setups. However, its still 
not strict enough.. you can still plug in "local"-hooks for anything.. this 
is a flexibility that is unfortunately still too often abused (thank kdevelop 
or KDE studio). 

The only thing that bit-rotted quite much is our configure system.. since 
everybody just dared to touch it when something was broken.. there was hardly 
any cleanup work done. And just by quickly browsing over it there are so many 
things you CAN clean up without loosing any functionality.. factoring out 
common parts.. simplifying the logic, removing dead code. 

so if there is the possibility to plug in another configure system after we 
cleaned up our mess and structured it better, then we should do that. but 
don't try to solve problems that don't exist - our build system *is* flexible 
enough.. it is easy to use for things that are easy, and complex to use for 
things that should be rare (like conditional compiles for small issues). This 
is a *good* thing, because it will help keep things clean and maintainable.


-- 
Dirk//\