bksys / scons (Re: win32 port)

[Matt Rogers]

On Saturday 07 January 2006 07:10, Nagy Thomas wrote:
> > All in all, I'm not sure how the collaboration with
> > the scons people goes - whether
> > we can contribute a much improved configuration
> > framework, or whether the
> > only choice is to keep forking more and more stuff.
> > And that's only about the
> > configuration part, but apparently ita is reworking
> > the rest of scons too... ?
>
> Some refactoring cannot harm.
>

Surely this can be done within the scons project itself.

> > ita, did you talk to the scons people about those
> > improvements?
>
> I did, and our requirements (like 'a good
> configuration framework') are wanted by many other
> people too. Scons is throttled by backward
> compatibility, and its (now very low) amount of
> developers with commit access.
>

Perhaps we could convince them that breaking backwards compatibility is 
perhaps the only way to move their project forward? Even the oldest of 
distributions should have python 2.2 and there is a windows version of it. Do 
we know why they insist on keeping backwards compatibility with python 1.5.2?

> For people who have not followed here is a summary of
> the main issues with bksys/scons at the moment (i am a
> bit negative):
> * performance for incremental builds must be improved

do you know where the performance problems are?

> * the source code of scons must be kept compatable to
> python 1.5.2

why is this an issue?

> * command-line handling is not compatible with
> autotools and difficult to fix

why does it need to be compatible? scons != automake

> * libtool-like library support is difficult to make
> * progressbar for monitoring targets being build is
> almost impossible to add
> * detection of headers, libraries and programs could
> be improved
> * control over the scheduler is None
>

if we do things correctly (as in the way scons wants us to do them) we should 
only need control over the scheduler so we don't attempt to link 4 things at 
once on the local machine. Perhaps i'm a bit naive and don't know all the 
issues, but that's the only reason I see at the moment for needing control 
over the scheduler.

> Replacing the scons engine in bkys may have more
> benefits than just patching scons and i am
> investigating on this. Though the code is not ready
> yet (so there is nothing to try or port to win32 for
> the very moment), some specs can be reviewed:
> playground/devtools/miniscons/experimental/DESIGN &&
> playground/devtools/miniscons/experimental/sample.py
>
>

IMHO, the best solution is to fix scons. Then we're not the only ones who gain 
from the fixes, because if we're having these problems, then others are bound 
to have them as well.
-- 
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20060107/3bacc98e/attachment.pgp