Re: [Boost-build] An option to prepend paths to %PATH% before executing a test built with a toolset

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 12:39:44

On 10/20/2015 3:03 AM, Ion Gaztañaga wrote:
> On 20/10/2015 3:36, Edward Diener wrote:
>> My experience with mingw(-64) is that you will not be able to
>> compile/link without the 'bin' directory of the mingw(-64) installation
>> being in your PATH. Since different mingw(-64) releases have different
>> paths it appears impossible to me that you can run more than one
>> mingw(-64) regression test at a time.
>
> With mingw-64 I have no problems when compiling-linking because I've put
> a .bat file that updates PATH and passes arguments to g++:
>
> using gcc : 4.7c++03 : c:/.../_mingw-scripts/gcc-4.7.bat :
> <cxxflags>-std=c++03 ;
>
> where gcc-4.7.bat is:
>
> @echo off
> set PATH=C:\Program Files
> (x86)\mingw-builds\x32-4.7.3-posix-dwarf-rev1\mingw32\bin;%PATH%
> g++ %*
>
> This works with older mingw-builds and newer mingw-w64 builds, at least
> in several compilers (I have gcc-4.6,4.7,4.8,4.9, and 5.1). I use
> link=static to run tests, I don't know if this helps a bit.

I tried what you are doing above ( with batch files ) previously but ran 
into problems which I could never figure out regarding missing DLLs. If 
'link-static' overrides whatever linking is normally done for a 
library's tests and also guarantees that all DLLs including the 
run-time-library are statically linked then your final executable, being 
standalone, should work without any of mingw(-64)/gcc's DLLs.

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

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.

> I could just try to put a
> copy of this DLL in %WINDOWS% directory, but if that DLL has no ABI
> compatibility, then each compiler will need a different path. Even with
> ABI compatibility, I would need to guess which is the most recent
> version and deal with additional dependencies.
>
> I don't know much about how Build works, but I see several properties
> are passed to the "run-path-setup", I just don't know if those could
> come from user-config.jam.