Re: [boost] [config] config.requires and simple_run

Subject: Re: [boost] [config] config.requires and simple_run
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2016-02-25 12:22:11

AMDG

On 02/25/2016 02:27 AM, John Maddock wrote:
> 
>> <snip>
>> 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
>> builds.
> 
> 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
> first.
> 

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

> - 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
environment)?

In Christ,
Steven Watanabe