bksys / scons (Re: win32 port)

[Alexander Neundorf]

On Sunday 08 January 2006 09:07, Ralf Habacker wrote:
...
> I think the most important point is to get in a working relation with
> the scons developers/maintainers. Is someone of the developers listed on
> http://sourceforge.net/project/memberlist.php?group_id=30337 known to
> anybody, so the he can contacted directly ? Or can some KDE e.V
> representives make an official request for a "how to work together" and
> "how to extend/optimize scons in area .... without breaking other stuff
> too much or giving an migration path"- or similar meeting with the scons
> people ?
>
>  From the scons development page (http://www.scons.org/dev.php)
>
> " ScCons design documents
> <http://sc-archive.codesourcery.com/entries/build/ScCons/ScCons.html>
> The original design, from the Software Carpentry
> <http://software-carpentry.codesourcery.com/> build tool contest, on
> which SCons itself was based. This is now of more interest as an
> historical document, since the current design has changed significantly
> as we figured out how to make things easier."
>
> Why should the recent design should not be changed  when ther are ways
> to make it more easier or faster ?
>
> To take the scons configure stuff as example, it should be possible to
> take the two or three related python files, make an extended design in
> coordination with the scons people and implement this (if someone is
> willing to learn how scons is implemented and have the time or is
> sponsered by someone else). Sure, it costs time (and money if done in
> worktime) and there will probably only very few people know scons
> internal very well (I hope at least two). But all this will not be
> possible, if we cannot came in good contact with the scons people.

Ok, I guess you already know what I'll write, anymway.
I followed this mailing list loosely.

I'd like to state again some things about cmake as the other alternative:
Pros:
-they offered to implement the things which are missing to build KDE (I don't 
know any currently)
-they have a fully working configure-like framework, dead-easy to use
-I managed to build almost complete kdelibs (KDE3) (I just stopped because 
recompiling everything when I noticed that I had forgotten something in 
config.h simply took too much time)
-cmake has no other dependencies except a C++ compiler
-cmake supports basically every UNIX, MS Windows (MSVC, Borland, cygwin, 
mingw) and Mac OS X (support for frameworks is not yet perfect)
-cmake can generate Makefiles and *projects* for KDevelop3, MSVC 6,7, XCode
-simple syntax (now case-insensitive commands, since some KDE developers 
didn't like the all-uppercase)
-it features a testing framework (ctest/dart, haven't used it myself yet)
-it supports: compiling libs, apps, KDE kparts, KDE ioslaves, KDE loadable 
modules, -enable-final, la-file generation (required for loading KParts 
AFAIK), KDE icon-installaton
-there is a am2cmake ruby script, which does maybe 90 percent of the work of 
converting Makefile.am's to cmake files (it doesn't: automatically generated 
tests to create a config.h, add custom include dirs and libraries)
-I added cmake files to compile software for KDE3 some days ago to svn, 
including sample CMakeLists.txt (generated by am2cmake): 
http://websvn.kde.org/trunk/KDE/kdesdk/cmake/kde3/

-simple and limited syntax in the cmake files, has pros and cons

Cons:
-the cmake commands for installing files are not very powerful, but they know 
this and if this would be the reason why KDE can't use cmake they would  fix 
it faster
-not sure: relinking during installation
-no progress percentage: this can not be done in cmake, since cmake is no 
buildsystem itself, it just generates input files for the native buildsystem

Bye
Alex
-- 
Work: alexander.neundorf at jenoptik.com - http://www.jenoptik-los.de
Home: neundorf at kde.org                - http://www.kde.org
      alex at neundorf.net               - http://www.neundorf.net