[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-buildsystem
Subject:    Strategy for choosing a build system
From:       holger-kde () holgis ! net (Holger =?iso-8859-1?q?Schr=F6der?=)
Date:       2006-02-03 23:41:40
Message-ID: 200602040041.40653.holger-kde () holgis ! net
[Download RAW message or body]

On Friday 03 February 2006 18:43, Jaison Lee wrote:
> > - cmake is much more mature at this point
> > - bksys will give a much nicer solution in the end
> > (most KDE developers prefer an object-oriented syntax, and an all-in-one
> > solution over generating Makefiles).
>
> In my mind the biggest issue with scons was the much-discussed
> SConfigure system. I took a couple stabs at SConfigure, but I wasn't
> able to come up with anything that I thought was an elegant
> implementation. Until someone comes up with something that works how
> can we even consider scons an option?
>
the biggest issue with scons as it is now is performance. it is unacceptable 
to wait for 90 seconds on a decent computer for scons to build up its 
dependency tree, when you are only working on a special file in a special 
subdir and want to compile it. as soon as this performance problem is fixed, 
all the rest is doable. but speeding up scons by a factor of 10 or better 100 
is really a heavy task.

> And I'm sure someone will eventually be able to build *some* sort of
> support for it, but can we even say we are using scons anymore? We'll
> have a local fork of scons running a unique configuration system.
> Saying we are using scons would be bit misleading I think, and we'll
> have to support it for the lifetime of KDE4 and probably beyond.
> Assuming the CMake devs are planning to wrap up their recent changes
> into a new release the CMake system will be same as any other, with
> maybe just a few bells and whistles here and there.

well, we are replacing automake with all its size and platform-dependencies.
when the scons system is only a few quite small files written in simple 
python, it will be a lot easier to maintain than all these Makefile.am, 
configure.in.in *.m4 and what else belongs to the current build system. the 
hard parts that have slowed scons development down were mainly the goals to 
provide a build system that works under mac os and windows too.
-- 
regards,

Holger Schr?der


[prev in list] [next in list] [prev in thread] [next in thread]