Subject: Re: [Boost-build] An option to prepend paths to %PATH% before executing a test built with a toolset
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-10-20 18:21:59
On 10/20/2015 4:30 PM, Ion Gaztañaga wrote:
> On 20/10/2015 18:39, Edward Diener wrote:
>>> I have no execution errors, even if PATH is not updated when executing
>>> (maybe those different runtimes in each compiler are compatible or they
>>> just embed some DLL lookup path in the binary, I don't know).
>> If your 'link-static' means that there are no DLLs of any kind then you
>> don't need the PATH set in any way at run-time, since you have a
>> standalone executable. But I don't know if 'link-static' actually works
>> this way given the different needs of all Boost libraries and the
>> vagaries of different mingw(-64)/gcc implementations.
> The exact option is "link=static runtime-link=static"
>>> The main problem is with the old mingw (I'm trying to test gcc-3.4 and
>>> gcc-4.2) which complains about mingwm10.dll.
>> I think you are trying to hard to regression test versions of compilers
>> which nobody seriously uses anymore. OTOH if you are only testing your
>> own libraries with these ancient compilers it is understandable if you
>> are still willing to support those compilers.
> Nobody in some industries. I work in places where the compiler isn't
> updated in many years.
>> As a solution to your problem try putting ( or making a symbolic link )
>> of each of your batch files in the appropriate 'bin' directory of the
>> mingw(-64)/gcc implementation. So your path to the batch file is the
>> same as the path to the g++ executable. I believe that for gcc Boost
>> Build automatically adds that directory to the front of the PATH when
>> running tests.
> Putting the .bat file in the bin directory works great.
Glad to know that worked.
> Now my
> compilation line for Mingw C++03 compilers is:
> link=static runtime-link=static
Thanks ! I will look at using your technique. Are you sure that
'link=static runtime-link=static' on the command line overrides whatever
a library's testing jam file might specify ? I recall that some
non-header only libraries might insist on testing out their
functionality using a DLL version of their library ( I think Boost
serialization, for one, does this, but there may be others ).
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