Boost logo

Boost-Build :

Subject: Re: [Boost-build] Python Port toolset.flags()
From: Juraj Ivanèiæ (juraj.ivancic_at_[hidden])
Date: 2014-10-14 10:20:05

On 13.10.2014. 23:52, Boman, Aaron wrote:

> I don't understand the purpose of this check, so I don't know how to
> correct this problem. bjam.caller() acts independent of the Python
> stack so I'm not entirely sure if it's possible to implement
> something similar.

I think I know what this check is about.
Here is how toolset.flags is supposed to work regarding

1) If there is a dot in rule-or-module
parameter then it is parsed as <module>.<rule>

If there is no dot in the rule-or-module parameter then
   2) toolset.flags considers it to be module
   3) except in case it is called from a jamfile - then it is
      considered to be a rule in the current jamfile.

Examples for 1) and 2) can be found in e.g. msvc.jam:

# case1
toolset.flags msvc.compile .RC ... ;

# case2
toolset.flags msvc YLOPTION : "-Yl" ;

The third option is here to make the following work:


toolset.flags do_something SOMETHING : "It works" ;

actions do_something ( )
     echo $(SOMETHING) ;

notfile something : @do_something ;


> `caller` is always going to contain some "Jamfile" and toolset module
> names (such as 'arm' in this case) are never going to contain a '.',
> so qualify_jam_action() is always going to be called and the toolset
> module name is going to be mangled. In this case, `rule_or_module`
> becomes "Jamfile<path/to/my/Jamroot>%arm"

In python port toolset modules aren't jamfiles, so they get skipped by
bjam.caller() and this check is no longer valid. In non-python bjam the
'caller' would be 'arm' because code would reside in arm.jam. The
correct condition should be something like '(caller is jamfile) and (we
are not processing an import)'.

I currently don't have the time to look into it further, but I hope this

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