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:
toolset.flags msvc.compile .RC ... ;
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 acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk