Testing launcher for toolset

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Testing launcher for toolset

Boost - Build mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: Testing launcher for toolset

Boost - Build mailing list
AMDG

On 7/22/19 5:09 PM, Edward Diener via Boost-build wrote:
> 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 ?
>

It's possible to do this via conditional toolset requirements.

toolset.add-requirements <toolset>ttt-nnn:<testing.launcher>test-setup ;

I thought the manifest was supposed to handle this, though.

> 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.
>

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Testing launcher for toolset

Boost - Build mailing list
On 7/23/2019 6:34 AM, Steven Watanabe via Boost-build wrote:

> AMDG
>
> On 7/22/19 5:09 PM, Edward Diener via Boost-build wrote:
>> 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 ?
>>
>
> It's possible to do this via conditional toolset requirements.
>
> toolset.add-requirements <toolset>ttt-nnn:<testing.launcher>test-setup ;
>

Great, I will try it.

> I thought the manifest was supposed to handle this, though.

Do you mean the 'manifest' generated by the clang-win toolset when an
executable is generated ? I did not realize that the Windows manifest
enables the executable to find all its DLLs at runtime. If it does then
I do not need to accomplish what I thought I did. Thanks for mentioning it.

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