Testing launcher for toolset

Edward Diener via Boost-build <[email protected]> Mon, 22 Jul 2019 19:09:50 -0400
Newsgroups gmane.comp.lib.boost.build
Message-ID <[email protected]>
Given some compiler toolset 'ttt' of release 'nnn', as in:

using ttt : nnn : etc. ;

is it possible to designate a single testing.launcher command for all 
'run' tests ?

If it is not currently possible, given that it is possible to specify a 
compile/link command for all compile and link tests using ttt-nnn via:

using ttt : nnn: compile-link-command : etc. ;

would it not be worthwhile to have the same functionality for all run 
tests ?

My real world need for this is: clang-win toolset defaults to whatever 
algorithm clang-cl uses ( probably just the latest version it finds on 
the system ) to choose a version of Visual Studio/VC++ to use as its 
backend. But this does not allow the end-user to control the Visual 
Studio/VC++ backend for a particular version of clang unless he can 
execute a particular version of VC++'s vcvarsall.bat ( or equivalent ) 
for initiating the VC++ environment before invoking clang-cl. This can 
be done for compiling/linking by using the compile-link command, via a 
script, as above for a particular clang-win-nnn toolset. But there is no 
equivalent for doing this prior to a 'run' test so that the correct DLLs 
used when compiling/linking are found. One wants to specify a particular 
version of Visual Studio/VC++ for earlier versions of clang in which 
clang-cl may not work with the latest installed version of VC++.

My kludgy workaround for this problem is to simply execute a particular 
version of VC++'s vcvarsall.bat ( or equivalent ) prior to invoking 'b2 
toolset=clang-win-nnn etc.' in whatever command window I am running b2. 
This works, because the environment is passed down to all sub-processes, 
but I hate this kludge. If there were a means to specify a 
testing.launcher command for the 'run' test in the clang-win toolset 
definition just as there is a means for specifying a compile-link 
command in the toolsets ( and every compiler toolsets ) definition I 
would not need this kludge.

_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build