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

List:       kde-devel
Subject:    Re: scons
From:       Esben Mose Hansen <kde () mosehansen ! dk>
Date:       2005-02-12 12:49:40
Message-ID: 200502121348.03969.kde () mosehansen ! dk
[Download RAW message or body]

On Saturday 12 February 2005 11:57, Stefan Gehn wrote:
> Am Samstag, 12. Februar 2005 12:21 schrieb Stephan Kulow:
> > On Saturday 12 February 2005 02:15, Benjamin Meyer wrote:
> > You assume all windows developers have VC++ instead of gcc? I doubt that
> > compiling KDE without having to install cygwin first is a goal.
> >
> > Anyway, you're right that auto* needs a major rethinking for KDE4. But
> > I'm afraid scons and bksys are the answers to give. unsermake has already
> > the features you name as major scons features, but it still suffers from
> > the admin/ need. But I have ideas how to solve that.
>
> And unsermake should learn to keep its dependency list correct after
> changes in cvs that would not need a "make -f Makefile.cvs" otherwise. I
> doubt you never saw yourself starting unsermake several times until
> everything in kdelibs compiled ;)
> Other than that unsermake is quite useful already.

In any case, we shouldn't just use unsermake because it is made in conjunction 
with KDE. We should use it because it is the best tool for the job. IF the 
KDE project is seriously reconsidering using the auto* tools, we should look 
at all the alternatives, and determine which is better as objectively as 
possible. We need to establish criteria like:

* Platforms supported? The more platforms, the better
* Correctness? 
 - Does the tool build all necessary the targets? 
 - Does the tool 
* Workload
 - Work to built everything, a module, a subdirectory
 - Work to add a new file, a new target
 - Work to add a new module
 - Add new target types
* Integration with version control
 - Support for built from CVS? 
 - Other versioning systems supported?
* Speed
 - handling of "sparse" builds (mostly everything is built)
 - parralel building, cc caching, distcc integration
* Learning curve
 - Syntax? Languages
 - Documentation quality

Feel free to think up more. Then we should evaluate each of the systems 
considered, make up a table/chart and THEN make a decision. 

At least I think this would be better. Changing build system is no mean task. 

(Sorry about all the "we"s. I know I'm a very minor contrib, it's just my poor 
English).

-- 
regards. Esben
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]