kde binary building is not portable :(

[Stephan Kulow]

Am Wednesday 27 November 2002 17:44 schrieb Guillaume Laurent:
> On Wednesday 27 November 2002 17:30, Adriaan de Groot wrote:
> > Has anyone tried using AAP
>
> Given the dev status I wouldn't even consider looking at it for KDE. There
> was also a lengthy thread on the possibility of using cook :
>
> http://www.canb.auug.org.au/~millerp/cook/cook.html
>
> It also gives you parallel and distributed builds. I gave it a quick try
> and was able to write a cook file for qt code, handling moc files and
> everything, in just a couple of hours. The problem is still that porting
> KDE's build system to it would require a lot of time, and migrating all the
> existing makefiles would require even longer. Hence my asking for
> unsermake.

The discussion about cook was actually the inspiration to write unsermake
(the original name was meincook, but we changed the name :)

I use unsermake in my daily compilations because it works perfectly in the
distcc environment I use (automake's recursion makes it very hard to get
the full power of a distribution compilation). The TODO is actually pretty
small, but the major show stopper is kdepim's libical directory as it has
a build system within the build system which _requires_ recursion ;(

We thought about two solutions: change kdepim's way to build libical
or build in a quite complex solution within unsermake. So far I prefer the
second solution to keep automake compatiblity as far as possible, but
as it requires time, I stay without korganizer ;)

BTW: the reasons why most people dislike automake and autoconf (the
need to actually read manuals :) will most likely stay with unsermake, so
don't raise your hopes too high. But the reasons _I_ dislike automake
will go away (no perl anymore :)

Greetings, Stephan