Re: [Boost-build] Future development

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

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

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
descriptions, yet.

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

Yes.

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

- Volodya