bksys / scons (Re: win32 port)

[Jaison Lee]

I hate to add fuel to a conversation that has no doubt gone back and
forth already, but what *was* the primary reason that scons was
chosen?  As a newcomer looking things over I have been baffled at how
bksys is using scons. Most everyone here seems to think that the main
scons tree has intolerable problems, and there are so many layers
(especially once the "SConfigure" system gets made) that it barely
resembles what a normal scons build system looks like.

Don't get me wrong; I use scons at work and I really like it, but if
it isn't capable of handling KDE then why are we trying to make it do
so? Is it really worth keeping a KDE specific build system (which is
what we are moving towards)?

scons/bksys has been in development for months and yet it seems to be
months away at best from even being serviceable. Perhaps it's time to
cut our losses and run.



On 1/9/06, Alexander Neundorf <neundorf at kde.org> wrote:
> 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
> _______________________________________________
> Kde-buildsystem mailing list
> Kde-buildsystem at kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
>