From: Edward Diener (eldiener_at_[hidden])
Date: 2019-07-22 23:09:50
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
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.
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