Re: [Boost-build] b2 option parsing

Subject: Re: [Boost-build] b2 option parsing
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2016-10-30 22:04:04

AMDG

On 10/30/2016 07:34 PM, Stefan Seefeld wrote:
> On 30.10.2016 21:21, Steven Watanabe wrote:
>>
>>> And  what should I do for 'bar' "to be
>>> registered as a feature in order for it
>>> to be interpreted as a property of <bar>baz" as you say above ?
>>>
>> The function that handles this is build_request.from_command_line.
>> https://github.com/boostorg/build/blob/develop/src/build/build_request.py#L108
>> This won't work at all without large parts
>> of Boost.Build however.
> 
> I'm not using the above module at all. What do I need to do for jam not
> to interpret (parts of) the command-line arguments (options, features,
> targets, etc.) ? Can you resume conceptually how the above (i.e., the
> existing Boost.Build logic) extracts features such as "toolchain=gcc"
> from the command line such that jam.c doesn't wrongly interpret this as
> the name of a target ?

  If you're bypassing build_system.py, then Boost.Build's
option processing will be skipped.  The only option
processing that will happen is the built in b2 option
processing which cannot be disabled in any way because
it happens before any Jam/Python code is executed.
What you can do is replace the list of targets
before b2 tries to build them by calling UPDATE
(which I thought you were doing, so there's something
weird happening here).

>>> Further, calling `../../src/engine/bin.linuxx86_64/b2` from an example
>>> directory yields
>>>
>>> ...found 3 targets...
>>>
>>> is there a way to have 'b2' print out the names of those 3 targets, or
>>> even introspect them using the "bjam" module (or some other API for that
>>> matter) ?
>>>
>> -d+12
> 
> Thanks. Is there a way to access that programmatically ?
> 

No.

In Christ,
Steven Watanabe