Subject: Re: [Boost-build] Running check-target-builds against a target every time
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-06-01 17:45:08
On 6/1/2016 3:33 PM, Steven Watanabe wrote:
> On 06/01/2016 10:59 AM, Edward Diener wrote:
>> I am invoking check-target-builds against a target in a jamfile, but I
>> need to run it each time it is invoked. Instead it is only actually
>> building the target once even if I invoke it multiple types in a
>> jamfile. How can I tell Boost Build that I want to build the target each
>> time it is invoked from check-target-builds ?
> Why do you need to build it multiple times?
> It should give the same result every time.
I am trying to pass different parameters to the rule which creates the
same target each time. I can't create a target for each possibility as
this involves theoretically from 1 to 28 different boolean possibilities
each time ( each possibility is a <define>some_macro=0 or
<define>some_macro=1 where 'some_macro' has 28 different names ). If I
limit the possibility to only one of the 28 different possibilities each
time I could create 56 different targets but I would very much like to
support more than one of the 28 different booleans each time. Even
supporting every combination of 2 of the 28 different boolean
possibilities each time quickly becomes totally unwieldy as to the
number of possible targets I would have to create.
So what I did was to specify a single target, which I would always want
to be attempted to be "built", where the target ( a compile of a source
.cpp file ) would fail to be built if the boolean possibilities did not
match some compiler-driven features ( which I test via preprocessor
The way I "passed" different parameters to the rule which creates the
target, since I could not see how to pass anything via the
check-target-builds invocation, was to have some variable hold the
"passed" information and then have the rule which attempts to build my
single target access that variable each time. Evidently this does not
work because check-target-builds appears to cache the command rather
than execute it immediately.
Even if I were to use separate targets with check-target-builds it seems
as if each target is fixed as far as information you can pass to the
rule which creates the target. For instance if I had:
rule create-some-target ( target-name : requirements * )
obj $(target-name)_obj : target_source.cpp : $(requirements) ;
unit-test $(target-name) : $(target-name)_obj ;
create-some-target my_target ;
how can I pass variable requirements when invoking:
check-target-builds my_target : a-true-property : a-false-property ;
? It is evidently impossible as my_target must have the requirements
in its create-some-target invocation, such as:
create-some_target my_target : <define>some_macro <include>some_path ;
>> I tried adding the line:
>> ALWAYS my_target ;
>> in the jamfile in which the target is being built but, alas, it did not
>> do what I desire.
> There are three reasons that it doesn't work:
> - check-target-builds uses an extra layer of caching so
> that targets that fail to build won't be rebuilt every time.
> This is unaffected by always.
> - always only forces a target to update once per b2 invocation.
> - The correct rule is "always", not "ALWAYS". (As a
> general rule ALL CAPS is for Jam builtins, which apply
> to the jam targets, not metatargets)
It does not look like I can use check-target-builds for building a large
number of different possibilities as I have described. Yet I would
definitely like some way of:
* Passing to the check-target-builds target Boost Build features, which
could be different each time.
* Having check-target-builds attempt to rebuild every time.
Is there any possibility of doing this with the current
check-target-builds implementation ?
I apologize for the long-windedness of my explanation but it seems as if
it should be possible to use check-target-builds in such a way that the
number of possibilities can be varied each time I want to build a target.
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