Subject: Re: [boost] [config] config.requires and simple_run
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2016-02-25 12:22:11
On 02/25/2016 02:27 AM, John Maddock wrote:
>> unfortunately I ran into problems with
>> simple_run_action. The problem essentially is
>> that this rule ignores RUN_PATH, which may be
>> set by some toolsets (a quick grep shows borland,
>> cw, gcc, and intel) to indicate additional
>> paths that must be added to PATH when running
>> the executable. In addition, I'm wondering
>> how this is supposed to work with a cross-compiler.
>> We really shouldn't be requiring cross-compilers
>> to have access to the target system for ordinary
> All good points: ideally this feature would simply use the regular "run"
> rule, but this breaks the regression testing for some reason :(
Did you try unit-test? It's essentially
a simplified version of run, that follows
all the usual Boost.Build conventions.
> BTW RUN_PATH seems to be under-maintained, because I've never managed to
> get Intel tests to run without manually setting up the Intel environment
testing.jam handles RUN_PATH correctly.
I just looked at intel-win, and it looks
like it's getting mixed up about native
paths vs. the format used by the Boost.Build
path module. (See attached patch, for my
best guess at a fix)
> The cross compiler issue is a good one - normally this rule is used only
> for testing rather than building the libraries
I wouldn't count on this remaining true in the
> - however it would be nice to have a better solution.
The only reliable way to deal with cross compilers
that I know of is to use only compile+link tests.
Are there any known cases where these tests link
but fail at runtime (other than a misconfigured
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk