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@cs.msu.su> 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