Boost logo

Boost-Build :

Subject: Re: [Boost-build] prototyping alternative Boost.Build syntax
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2016-10-28 09:42:46


On 28-Oct-16 4:31 PM, Stefan Seefeld wrote:
> On 28.10.2016 09:24, Vladimir Prus wrote:
>> Stefan,
>> On 28-Oct-16 4:12 PM, Stefan Seefeld wrote:
>> (I'd like to prototype a bit with a new (Python)
>>> syntax, and therefore need to hook up my own parser to feed b2 the
>>> objects it expects.
>> If you're doing that, you should be working with Python port, and then,
>> things are much simpler. b2 is merely starting Python interpreter, and
>> starts Python code. It also gives Python a few functions to put together
>> a lowest-level dependency graph.
> OK. Are there any resources that could help me understand the above ?
> For example, what exactly is that "python port" ? Is the "b2" engine
> itself being ported to Python ? I thought it's only Boost.Build that was
> being ported, which is why I was wondering about the exact relationship
> between b2 and Boost.Build.

There is, but it's quite
brief. Boost.Build has two parts, b2 executable which is a low-level
build engine and Jam language interpreter, and Boost.Build proper, which
is implemented in the Jam language and has all the smarts. Python port
rewrites the latter in Python. When b2 is built with Python support, the
Python port can be used by passing --python on the command line.

>> The code in Jamfiles is intepreted by b2, but it mostly calls Python
>> functions that that whatever they please. So,
>> exe a : a.cpp ;
>> pretty directly calls this Python function:
>> which does:
>> return self.manager_.targets().create_typed_target(
>> type, self.registry.current(), name, sources,
>> requirements, default_build, usage_requirements)
> OK. Is there a (more or less formal) description of "usage requirement"
> as well as all the other concepts involved ? (I'm really trying to grasp
> this on a conceptual level to be able to play around with new syntax
> without questioning the established semantics, i.e. the underlying model.

This is documented at

Requirements and usage requirements are properties of metatarget, one
adjust properties used to build metatarget and another specifying
properties that must be returned to all dependents.

>> Native Python build description would have 'manager' variable injected
>> in scope, and do exactly the above :-)
> Hmm, I think I'm now even more confused than before, as I don't know
> what I should be looking for / at. ;-/

Oh, so right now the process, when using Python port is:

- Boost.Build loads Jamfile.jam, arranging for 'exe' function to be
visible for the loaded code. The implementation of 'exe' is what I
  have shown above.
- The loaded code calls 'exe', passing name and list of sources
- The function that 'exe' was creates an instance of metatarget
- After loading Jamfile, Boost.Build generates all metatargets, and gets
  a list of targets, which are then passed to build engine to build

In Python port with Python build description, it would be:

- Boost.Build loads (hopefully we'll find a better name),
arranging for 'exe' function to be in scope.
- Everything else is the same.

Does this help?

Vladimir Prus

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at