Re: [Boost-build] prototyping alternative Boost.Build syntax

Subject: Re: [Boost-build] prototyping alternative Boost.Build syntax
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-10-28 09:58:30

On 28.10.2016 09:42, Vladimir Prus wrote:
> Stefan,
>
> 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 https://github.com/boostorg/build/wiki/Python, 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.

OK, so b2 will - when compiled with --python - contain both a Jam
language interpreter as well as a Python interpreter ?

>
>>> 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:
>>>
>>> https://github.com/boostorg/build/blob/develop/src/build/project.py#L1003
>>>
>>>
>>> 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
> http://www.boost.org/build/doc/html/bbv2/overview/targets.html
>
> 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.

What is a "metatarget" ? :-)

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

OK, so "exe" is a rule to build an executable target (file) from one or
more sources ('a' from 'a.cpp' in the above case).

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

OK.

>
>
> In Python port with Python build description, it would be:
>
> - Boost.Build loads Jamfile.py (hopefully we'll find a better name),
> arranging for 'exe' function to be in scope.

I assume the "exe" rule is also defined in some Jam code snippet
somewhere. How does b2 internally represent rules (and associated
actions) ? I'd assume that internal representation doesn't depend on
whether the definition comes from Jam or Python ?

(In my mental picture b2 holds a graph where targets are the nodes and
rules are the edges, while actions are the functions that remake
targets, so its main role is to analyse that graph and schedule the
required actions to rebuild the target the user has requested
(implicitly or explicitly). Right ?

> - Everything else is the same.
>
> Does this help?
>

It does, thanks !

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...