Re: [Boost-build] Future development

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

Yep.

> - 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
> adequate

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
> 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 
declarative.

[ 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
> 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.

/ Johan