Subject: Re: [Boost-build] Status of b2 and all the python tools in the build directory?
From: Vladimir Prus (ghost_at_[hidden])
Date: 2013-12-24 11:10:48
On 20.12.2013 17:45, Nogradi, Chris wrote:
> On Friday, December 20, 2013 12:17 AM, Vladimir Prus wrote:
>> On 20.12.2013 08:23, Steven Watanabe wrote:
>>> On 12/19/2013 10:14 AM, Jess wrote:
>>>> Was the idea to replace Jamfiles or keep them more or less the same but allow for python logic?
>>> Jamfiles would be mostly unchanged. Only the internal implementation and extension interfaces would use Python.
>>>> Was the idea abandoned because fresh starts like SCons made more sense?
>>> I don't think it's been explicitly abandoned. It's just that no one has put in the work to make it happen. I'm not personally
>>> interested in it, because it seems like a lot more effort than it's worth.
>> But it it magically ends up in feature-parity state with the current codebase, would you be willing to switch over?
> Well we have been eyeing a switch to python, mostly to take advantage of any performance improvements (we still need about a 50% speed
> increase to get complete boost-build buy in for all projects). However, with all of Steve's latest improvements, there may be no
> additional gain? We were hoping to hack together a simple test to compare the performance of it. We currently do not use boost.python
> but do use msvc, gcc and our own arm (ads1.2 and ds-5) and adi blackfin. So I am guessing that it should not cost too much to switch to
> the python port assuming there are speed improvements to be had? Though I am mostly indifferent (except when I need more than what jam
> provides, like math), there are many here that would prefer to look at python rather than jam.
It seems that in your situation, the switching can be easier that it is for Boost. I would suggest that you hold on for a while though -
I am planning to make another pass of Python-vs-Jam resync in next couple month, and then it will be clearer what's missing and what's
working. I think there will be performance difference in all cases.
> Also, is there still momentum for boost to switch to CMake? I would be very disappointed to see boost.build no longer supported by its
> main (and only?) opensource project.
As you can see, git transition was not exactly smooth and is not over yet, which suggests that infrastructure is hard, and there
are not many people who care to work on it in practice. So, I am not much concerned over CMake.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk