Re: [Boost-build] Conditional unit test execution

Subject: Re: [Boost-build] Conditional unit test execution
From: A. Schamp (schamp_at_[hidden])
Date: 2014-05-19 10:56:01

We've been using this for a while and it has been working, but we tried
creating a release build for the first time, and ran into trouble (we had
only been building debug builds).

It appears that, when variant=release, the <define>BOOST_TEST_DYN_LINK and
<define>BOOST_TEST_MODULE=$(...) are being lost in the property set.  When
I try to debug it (by adding:
echo "Property set: " [ $(property-set).str ] ;
to the run rule in the generator), it shows those <define>s when I run with
variant=debug, but not with variant=release.

I'm afraid what's going on with the generator is rather obscure to me -- I
can't find documentation that helps me understand it.  Is there something
else I must be doing to ensure that the <define>s get passed in for both
cases?  or is there some kind of bug here?

As a refresher, here's a snippit of what I've currently got:

    type.register TSS_TEST ;

    class tss-test-generator : generator
    {
        import "class" : new ;
        rule __init__ ( * : * )
        {
            generator.__init__ $(1) : $(2) : $(3) : $(4) : $(5) : $(6) :
$(7) : $(8) : $(9) ;
        }
        rule run ( project name ? : property-set : sources * )
        {
            echo "Property set: " [ $(property-set).str ] ;
            local type ;
            if [ $(property-set).get <toolset-gcc:version> ] = ppc
            {
                type = LINK ;
            }
            else
            {
                type = RUN ;
            }
            return [ generators.construct $(project) $(name) : $(type) :
$(property-set) : $(sources) ] ;
        }
    }

    generators.register [ new tss-test-generator tss.test : : TSS_TEST ] ;

    # a helper rule to wrap the build stuff common to all boost.test test
cases
    rule run-test ( target : source : requirements * : properties * )
    {
        tss-test $(target) : $(source) boost_prg_exec_monitor
$(requirements) : $(properties) : <define>BOOST_TEST_DYN_LINK
<define>BOOST_TEST_MODULE=$(source:B) ;
    }

We invoke the run-test rule something like this:

run-test foobar.test.test : foobar.test.cpp : :
<testing.arg>--log_format=HRF <testing.arg>--log_level=warning ;

Ultimately, it fails to link because of "undefined reference to main" which
is what you get if BOOST_TEST_DYN_LINK  and BOOST_TEST_MODULE aren't
defined.

Thank you,
Andrew

On Tue, Feb 4, 2014 at 5:15 PM, A. Schamp <schamp_at_[hidden]> wrote:

> Ah, I see, that makes sense.  Thank you for the explanation!  It took me a
> while to figure out how to pass properties and requirements in, mainly
> because the way the testing rules allowed <testing.args> properties to be
> entered without the <testing.args> property tag.  Once I got that sorted
> out, it worked like a charm.
>
> Thanks a bunch,
> Andrew
>
>
> On Tue, Feb 4, 2014 at 12:56 PM, Vladimir Prus <ghost_at_[hidden]> wrote:
>
>> On 04.02.2014 22:40, A. Schamp wrote:
>>
>>> Volodya,
>>>
>>> Thank you for such specific help.  I think I understand the concept of
>>> the generator and the meta-targets a little bit better.  I don't
>>> quite see whether I can integrate that with the 'run' and 'link' rules
>>> provided by the testing.jam package, which has features (re-running
>>> tests if targets change, etc.) that we'd like to retain.  Is such a
>>> thing possible, or would we have to roll our own in some way?
>>>
>>
>> Andrew,
>>
>> actually, I think my example does exactly that - for RUN target. If you
>> replace EXE with LINK in the example it should be fully
>> identical. LINK type is declared in testing.jam and is effectively
>> creating EXE type and then some extra reporting on top.
>>
>>
>>  We are using <target-os>linux in both cases, but I presume another
>>> property (architecture or toolset) could be accessible in a similar way?
>>>
>>
>> Yes, indeed. You probably can check for 'gcc-pcc' as value of <toolset>
>> or for 'ppc' as value of <toolset-gcc:version> feature, or
>> whatever else is suitable. You can use --debug-building to see what
>> properties are used for generating metatagers and you can use
>> --debug-generators for an actual generation projects, though the output
>> will be large on real projects; you might want to play
>> with examples.
>>
>>
>> - Volodya
>>
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/
>> mailman/listinfo.cgi/boost-build
>>
>
>