Re: [Boost-build] [run] parameter containing the build directory - segmentation fault

Subject: Re: [Boost-build] [run] parameter containing the build directory - segmentation fault
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2016-10-16 18:17:27

AMDG

On 10/16/2016 03:00 PM, Raffi Enficiaud wrote:
> Le 10/10/16 à 16:47, Steven Watanabe a écrit :
>> <snip>
>> rule set-sink ( properties * )
>> {
>>   local ps = [ property-set.create $(properties) ] ;
>>   local path = [ $(ps).target-path ] ;
>>   return <testing.arg>--log-sink=$(path)/smoke-ts-sink.xml
>>          <testing.arg>--log-format=XML ;
>> }
>>
>> Then, you can use <conditional>@set-sink in
>> the requirements of the test case.
>>
> 
> 
> I tested several things, and I am quite not there yet.
> The value here in path gets expanded to eg. "clang-darwin-4.2.1/debug"
> while what I need is the same as the "testing.capture-output" line
> which indicates
> "../../../bin.v2/libs/test/test/bt-st-txml-0.test/clang-darwin-4.2.1/debug/bt-st-txml-0.run".
> 

  Right.  You need to prefix it with the
project's build directory. You can get this with
local p = [ project.current ] ;
local build-dir = [ $(p).build-dir ] ;

  I'm a bit surprised that b2-st-txml.test
doesn't show up, though.  The
<location-prefix> is set by testing.make-test
which is called by run, so it should
be present.

> 
> I also make the assumption that the tests are run from the current
> directory.
> From your snipet, I just changed to
> 
> local path,relative-to-build-dir = [ $(ps).target-path ] ;
> 
> and declared the run as
> 
> [ run smoke-ts-static : : : <conditional>@set-sink :
> $(test-name-prefix)-0 ]
> 
> Now I have also some other questions related to that:
> 
> - I tried to make "set-sink" dependent of other variables, such that I
> can expand the variables for the final "<testing.arg>", however I was
> not able to do so.
> 
>   - is the "rule set-sink ( properties * )" the signature for
> conditionals? or can I add another parameter?
> 

  Yes, that's the signature.  No, you can't add
more parameters.  The rule is called by Boost.Build
with a list of properties.  If you added more parameters,
Boost.Build wouldn't know what to do with them.

>   - can I have a rule returning a local rule and can a local rule
> capture local variables? I tried this
> 
> rule set-sink-outter ( logger )
> {
>   rule set-sink-inner ( properties * )
>   {
>     local ps = [ property-set.create $(properties) ] ;
>     local path,relative-to-build-dir = [ $(ps).target-path ] ;
>     return <testing.arg>--log-sink=$(path)/smoke-ts-sink.$(logger)
>            <testing.arg>--log-format=$(logger) ;
>   }
> 
>   return <conditional>@set-sink-inner ;
> }
> 
> and called the run like this
> [ run smoke-ts-static : : : [ set-sink-outter XML ] :
> $(test-name-prefix)-0 ]
> 
> but could not make it work. Any suggestion?
> 

  Variables in Jam have dynamic scope, not
lexical scope.  If you want to capture
variables, you'll need to define a class.
See build/configure.jam for an example of
using a class with <conditional>.

> - I understand "<conditional>@set-sink" as a "pointer to set-sink
> function". Is that correct?

Yes.

> - by parsing some other Jam files in boost, I also saw
> "<conditional>%something". What would the "%" mean?
> 

  I think this means to look up "something"
in the global module.  You can put a module
name before the %.  Note: Just to avoid confusion,
as far as the Jam language itself is concerned,
it's just a string.  The use of % comes from
the indirect module which is used to represent
function pointers as strings in a way that is
(mostly) reliable.

In Christ,
Steven Watanabe