bksys / scons (Re: win32 port)

Mon Jan 9 19:04:07 CET 2006

A Dilluns 09 Gener 2006 18:33, Jaison Lee va escriure:
> 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.

I *could* agree here, iirc scons was choosen because:
a) we wanted something to replace auto*
b) we did not want to create a Kde-only solution 

We are falling into the b) situation now, so we maybe should reevaluate 
things.

Albert

>
> 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
>
> _______________________________________________
> Kde-buildsystem mailing list
> Kde-buildsystem at kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem

______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y moviles desde 1 centimo por minuto. 
http://es.voice.yahoo.com