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 ;
                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,

On Tue, Feb 4, 2014 at 5:15 PM, A. Schamp <schamp@gmail.com> 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,

On Tue, Feb 4, 2014 at 12:56 PM, Vladimir Prus <ghost@cs.msu.su> wrote:
On 04.02.2014 22:40, A. Schamp wrote:

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?


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