From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-10-02 08:49:28
Just my personal comments:
Vladimir Prus wrote:
> With Milestone 12 out of the door, it's time for some
> planning. I personally think, for quite some time,
> that there are two important issues with Boost.Build:
> - Documentation
> - 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.
> - The features and performance of language are not
Will Python be any faster?
> Bjam does have an important advantage -- it's standalone, but I
> don't think this advantage outweights the problem.
Perhaps not, but it's still a big advantage.
> 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
> 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
[ 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?
> Of course, while working on Python port it's better not to touch
> code too much. So, non-Python development will be limited to local
> and to documentation writing.
> I envision the following plan of work:
> - 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.
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