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