On 8/17/2015 4:18 AM, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: 12 August 2015 01:16 To: boost@lists.boost.org Subject: Re: [boost] [build] Algorithm for setting PATH when a 'run' or 'run-fail'
On 8/11/2015 2:33 PM, Edward Diener wrote:
What is the algorithm for setting a PATH on Windows when the 'run' or 'run-fail' rule occurs in a jamfile ?
In running clang on Windows when an executable is created the PATH needs to start with the bin directory of the mingw(-64)/gcc implementation that a particular version of clang uses as its RTL when the program is compiled/linked. It appears that when the 'run' or 'run-test' rule occurs with the clang toolset on Windows that the PATH is adjusted to have the directory of the clang++ executable and not that of the corresponding mingw(-64)/gcc RTL ? Is there any solution to this from within Boost Build ?
I figured this out. Please ignore.
Maybe you could share your solution with us. I have a problem using Clang that might be caused by this.
First mingw(-64)/gcc --- Setting the PATH must be done in the individual .jam file for a particular compiler. I can see, using the b2.exe -d2 switch, that when I use mingw(-64)/gcc on Windows that there is a line that prepends to the Windows PATH a number of directories ( including the 'bin' directory ) off of the parent of the one I specify as as the gcc executable in my user-config.jam whenever a 'run' or 'run-fail' is invoked in a jam file. I am not sure where it is in the jam file ( I haven't looked ) but it must be there somewhere. Another interesting feature of mingw(-64)/gcc is that the 'bin' directory of any given implementation must be in the Windows PATH just to compile/link with mingw(-64)/gcc !!! Here is the logic for this as given to me by the mingw-64 developers: "Since you will need the 'bin' directory to be in the PATH in order to run a program created by mingw-64/gcc ( because of the DLLs there ) we force you to have the 'bin' directory in the Windows PATH when you compile/link." In other words it is not enough to simply invoke gcc or g++ with the full path of the executable. The mingw(-64)/gcc developers have cleverly set the directory structure in such a way that doing so will not work. Isn't that brilliant ? My solution to this is that my executable path for a particular mingw(-64)/gcc implementation, in my user-config.jam, is actually a batch file in the implementation's 'bin' directory which prepends the 'bin' directory path to the Windows PATH and then invokes the g++ command. This works fine whenever I use it manually to test a particular library. My batch file sets the PATH for compile/ink time and the individual gcc .jam file evidently sets it for 'run' or 'run-fail' time. What is mysterious, and I still have not figured this out, is when I try to run regression tests with various versions of mingw(-64)/gcc there are run-time failures where mingw(-64)/gcc DLLs are not being found. Second clang --- I can also see, using -d2, that setting the PATH for 'run' and 'run-fail' is not done for the clang jam file. The obvious reason for this is that clang does not use anything in its own 'bin' directory at run-time, but rather uses whatever is in the 'bin' directory of the mingw(-64)/gcc implementation which it uses as its RTL. So the problem with clang is: the Windows PATH must point to the particular implementation of the mingw(-64)/gcc it is using both at compile/link time and at run-time. I solve the compile/link time problem for clang like I do for mingw(-64)/gcc, since I also test multiple implementations of clang. My clang executable, in user-config.jam, for any given implementation of clang, is actually a batch file which prepends the PATH of the particular mingw(-64)/gcc implementation's 'bin' directory to the Windows PATH and then calls the appropiate clang++ executable. However at run-time I must use a different solution. My solution is based on the fact that clang 3.4+, clang 3.5+, and clang 3.6+ can only use the mingw directory structure ( and not the mingw-64 directory structure ) for its mingw/gcc implementation and that those implementations only look in c:\mingw for its implementation. For the soon to be released clang 3.7 and the current source clang 3.8 those restrictions are lifted. So what I do anyway, to solve the run-time problem, is put 'c:\mingw\bin' permanently at the end of my Windows PATH and for any given clang implementation my compile/link batch file: 1) Does a 'rmdir c:\mingw' if it exists. 2) Does a 'mklink /d c:\mingw some_mingw(-64) implmentation. 3) Does what I said above: prepends the PATH of the particular mingw(-64)/gcc implementation's 'bin' directory to the Windows PATH and then calls the appropiate clang++ executable. This is all ver kludgy but does work when I test out clang manually against various Boost libraries using bjam. Needless to say I really don't like the earlier version dependence of clang's reliance on c:\mingw at all. If some executable, created through mingw(-64_)/gcc or clang is being run from outside the bjam testing environment it will fail because the run-time path of the appropriate mingw(-64)/gcc RTL will not be set. I think this is what is happening with running the regression tests. Of course I can stick some mingw-64/gcc implementation's bin directory in the Windows PATH permanently, to solve all run-time problems, but then I couldn't test multiple versions of gcc and clang. No doubt the clang jam file should be updated to somehow automatically prepend a mingw(-64)/gcc RTL implementation specified by the user to the Windows PATH for the 'run' and 'run-fail' situations. If I really knew bjam, rather than having just dabbled at it, I could probably do this. But I have never really studied bjam and Boost build, and like others, have just dabbled at it long enough to do a few really simple things. The syntax still bothers me as well as the difficulty of actually understanding how things work and what functionality is available.