From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-10-02 09:18:10
On Tuesday 02 October 2007 16:49:28 Johan Nilsson wrote:
> > - Using language nobody can grok
> > The documentation is obvious issue -- there's much
> > more material to be added, and some editing to be done.
> > The language issue is different. When we started Boost.Build V2,
> > we talked if using bjam is good. I believe we decided to try,
> > and to use something else if bjam will prove insufficient.
> > At this point it's safe to say that bjam's build engine, while
> > scary, is pretty much up to task. At the same time, bjam's language
> > is not. We've extended it with object oriented syntax, and with
> > modules and what not, but still:
> > - Almost nobody know jam language
> True. However, having the various BBv2 jam "libraries" (set, path, etc...)
> documented with examples would probably help out.
Which is not necessary for Python -- at least basic data structures are already
> > - The features and performance of language are not
> > adequate
> Will Python be any faster?
Yes. Python, unlike Jam, has a full array of data structures. It also
has ref-counting, unlike Jam where an object created anywhere for
any purpose, keeps using memory forever.
> > In light of that, I think that the future of Boost.Build is a Python
> > implementation. We actually have a beginning of said port, but it
> > needs
> > more work. I'll soon post more details of what state that port is, and
> > what work is necessary. The important points however:
> > (1) This is going to be 1<->1 port. Until we pass all tests,
> > no behaviour changes should be done.
> > (2) We'll still be using bjam build engine, and Jamfiles as
> > description language
> Ok. If this holds true I guess I'd be pretty satisfied with a Python port.
> One of my main concerns regarding a port is that Python isn't really
Stefan was telling me it's possible to invent some nice syntax in Python,
but I'm not sure how. Anyway, we're not about to use Python for target
> [ I'm by no means an Scons expert, but those builds scripts makes Jamfiles
> look like a dream in comparison. ]
> > (3) Code that *extends* Boost.Build will have to be written
> > in Python -- in particular, generators will have to be in Python.
> > This will require update to user's projects, but given (1) the
> > update should be simple.
> Only if there are custom generators, I hope.
> > (As a technical note, base
> > generators classes will be in Python, and having custom generators
> > in Jam language deriving from Python classes is not a nice idea)
> Is it technically possible?
It is *probably* possible, but will be rather hard to get right.
> > Of course, while working on Python port it's better not to touch
> > original
> > code too much. So, non-Python development will be limited to local
> > bugfixes,
> > and to documentation writing.
> > I envision the following plan of work:
> > M13:
> > - Boost Trac issue #1228 (gcc/AIX)
> > - Boost Trac issue #1177 (stlport changes)
> > - Boost.Build trac issue #4 (relevant features)
> > - Sort out 4 failures on msvc
> > - Sort out 'gettext' test failure
> > - Couple of more minor bugs
> Please, fix/implement Boost.Build trac issue #83 as well (add support for
> specifying files with same name but different subdirectories). Does this
> break anything that doesn't rely on undocumented behaviour? At the very
> least, make it available with a command-line switch.
> I'm finding myself consistently putting warts in source files names to have
> them unique within a project.
IIRC, that ticket was stuck on ublas tests, which were using strange
arrangement of directories. I've moved #83 to M13, and look into it.
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