AMDG I've just been trying to get MinGW working without requiring the compiler's bin directory to be in the PATH. It mostly works now, but 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. In Christ, Steven Watanabe
I've just been trying to get MinGW working without requiring the compiler's bin directory to be in the PATH. It mostly works now, but 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 :( 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. The cross compiler issue is a good one - normally this rule is used only for testing rather than building the libraries - however it would be nice to have a better solution. John.
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
AMDG On 02/25/2016 10:22 AM, Steven Watanabe wrote:
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)
Ignore this. testing.jam calls path.native, so this can't be the problem. In Christ, Steven Watanabe
Did you try unit-test? It's essentially a simplified version of run, that follows all the usual Boost.Build conventions. No, and as far as I can tell it works OK - tentatively committed to develop.
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)?
Yes, |BOOST_NO_COMPLETE_VALUE_INITIALIZATION springs to mind, but I'm sure there are others (||BOOST_NO_CXX11_HDR_REGEX is another as GCC had a signature-correct, but non-functional <regex> for a while). I would have to check the test cases to be sure. John. |
participants (2)
-
John Maddock
-
Steven Watanabe