Boost logo

Boost-Build :

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-19 21:36:50

On 10/19/2015 6:47 PM, Ion Gaztañaga wrote:
> Hi,
> Forgive me if this was previously solved, I couldn't find anything about
> this in the archives.
> I'm trying to setup several mingw targets for my regression tests. I'd
> like to run several mingw installations (each one with a different
> compiler and runtime DLLs) in a single b2 invocation (apart from
> simplifying things, it maximizes CPU as it parallelizes all toolsets
> automatically).

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.

Furthermore Boost Build will invoke any toolset definition it finds in
jam files ( like user-config.jam ) even if you are not using that
toolset in your b2 invocation. This means that all mingw(-64) toolsets
in, let's say, user-config.jam will always be invoked at least once
whenever you execute 'b2'. Since each mingw(-64) toolset needs to have
its own 'bin' directory first in the PATH to invoke the compiler I have
found it impossible to have multiple mingw(-64) toolsets in
user-config.jam. What I do to get around this limitation of Boost Build
is to symbolically link a particular user-config.jam appropriate for
only the toolset I am using when running 'b2'. But even with this "hack"
to allow me to test multiple mingw(-64) toolsets in Boost Build I know
of no way to run regression tests on more than one mingw(-64) toolset at
a time since each must have its own 'bin' directory first in the PATH
when running the regression tests and that is an impossibility as far as
I can understand how the regression tests are run.

> In the different Mingw installations, I need to adjust the path before
> executing a test, as the DLLs needed for each toolset reside in
> different directories.
> I've tried to modify "testing.jam" where the rule "run-path-setup" seems
> to do something similar with an option named "dll-path". However, I
> could not figure out how to pass a "compiler option" setting from a
> toolset to the "properties *" variable in rule "run-path-setup".
> The basic idea is:
> 1) Define in a toolset, a path to be searched for DLLs before executing
> an executable compiled with that toolset:
> using gcc : 4.3 : : <run-dll-paths>"C:/Programs/mingw-gcc-4.3/bin" ;
> 2) Propagate that option into the $(properties) passed to
> "capture-output" and similar rules
> 3) Obtain that path in "run-path-setup":
> local run-dll-paths = [ feature.get-values <run-dll-paths> :
> $(properties) ] ;
> 4) Prepend it to PATH_SETUP
> I've tried to hack it myself trying to imitate other rules, but after a
> couple of hours I just gave up with. Any similar feature that I might be
> missing? Any hint on how this can be implemented (I really know very
> little about Boost.Build)? Is this feature useful enough to add it to
> Boost.Build?
> Best,
> Ion

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at