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.

On 8/18/2015 9:51 AM, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: 17 August 2015 21:04 To: boost@lists.boost.org Subject: Re: [boost] [build] Algorithm for setting PATH when a 'run' or 'run-fail'

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 ?

<big snip>

Sigh - what a shambles :-(

I'm amazed that you still have the will to live!

<g>. Actually I just like to test Boost code on Windows with something other than any of the 6 different VC++ releases ( 2008 through 2015 ) I could use ( well let's applaud Microsoft for putting out 6 different releases in 7 years ). I know that gcc and clang are technically better C++ standard conforming compilers than VC++ and I am too much comfortable with Windows to use any of the Linux distros I could also run very much.

Have you any experience of using http://tdm-gcc.tdragon.net/about or do you use mingw-builds or mingw-64?

Prior to mingw-64 I used mostly mingw/gcc from Sourceforge with an occasional foray into TDM. With mingw-64 I use the all-purpose mingw-w64-install.exe program, which works quite nicely. I have found mingw-64 to be better than mingw, but all mingw(-64)/gcc implementations have the problem I described where you can't even compile/link by just invoking 'some_mingw_gcc_implementation_path/bin/g++ command_line_parameters...' but must either do it from within the 'some_mingw_gcc_implementation_path/bin' directory or have the 'some_mingw_gcc_implementation_path/bin' in the Windows PATH. It is absolutely fruitless arguing with the mingw(-64) people that this restriction should not be necessary. These people are absolutely brain-dead if you argue against their "chosen way", ie. they chose it so it must be technically right.

...

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.

Would asking on the Boost-build for help from Bjam Gurus help?

No, such questions are never answered on that mailing list. Even simpler questions I ask there are usually unanswered. The assumption appears to be that if you want answers, beyond what is in the documentation, you need either a very specific case or you need to understand bjam and study the actual Boost build distributed jam files which make up the system.

Lots of things are possible - if you know how.

I am sure. I need the energy and will to understand Boost build and bjam but somehow lack it.