|
|
Boost Testing : |
Subject: Re: [Boost-testing] setup to test mngw- ...
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-10-18 22:03:03
On 10/18/17 2:20 PM, Edward Diener via Boost-Testing wrote:
> On 10/18/2017 12:21 PM, Robert Ramey via Boost-Testing wrote:
> 8) Now comes the difficult part which I know you are not going to like.
LOL
> Just don't curse me, but curse mingw-64/gcc instead. In order to
> compile, link, or run, the gcc bin directory must be in your Windows
> PATH; it is not good enough to execute g++ from the correct directory.
> This is a major PITA, because whenever you invoke, as above 'b2
> toolset=gcc-7.1'
> C:/Utilities/mingw-w64/i686-7.1.0-posix-dwarf-rt_v5-rev2/mingw32/bin
> better be in your PATH or else nothing will work because gcc-7.1 will
> not find what it needs.
> 9) Furthermore b2 used to test every toolset in user-config.jam even if
> you were not invoking that toolset via a 'b2 toolset=something". This
> meant that if you had multiple gcc toolsets in your user-config.jam for
> gcc, the b2 invocation would fail because it is impossible to have the
> bin directory for all those multiple toolsets first in your PATH at the
> same time. I believe Steve Watanabe fixed this but I am not sure.
> 10) So my setup, when using a version of gcc as the toolset is that I
> have a separately named user-config.jam for each gcc toolset, with names
> like user-config.gcc-7.1 etc, and then before invoking the gcc toolset I
> do a symbolic link to user-config.jam from user-config.gcc-7.1 etc and
> then I invoke 'b2 toolset=gcc-7.1 ...".
> 11) You can complain to mingw-64/gcc ( it is even worse with mingw/gcc,
> but almost no one uses that anymore ) about the stupidity of requiring
> the particular mingw-64 bin directory to be in the Windows PATH in order
> that the g++ command finds the libraries and include files and whatever
> else it needs in order to compile, link, or run an executable; but they
> will not care and just cite to you that VC++ sort of does the same.
>
> That is my recipe ! If you have any questions about it please ask and I
> will try to help you mas much as I can.
Actually I did the above - or something similar had had the same hassle
regarding the path, etc. I got disgusted and uninstalled the whole
thing. Then I installed Cygwin - which uses it's own shell which looks
like a unix environment even though it builds and invokes windows
executables. Without much pain, I bootstrapped boost build and ran my
whole build/test suite. It took forever though. And of course a bunch
of tests failed for a particular archive type xml - wide character.
After too much time I isolated this and got everying working spiffy on
cywgin. I uploaded develop branch and cross my fingers. Alas - still
I've got the same mngw issue.
I was really hoping that installing some version of MSYS with it's shell
would give me similar results to cygwin. But alas, there are multiple
versions of this just as there are for the mngw compiler. It appears
that there is the "official" one and the "better" one. It's quite
confusing. But your explanation has encouraged me to investigate this
further.
Thanks for your help.
Robert Ramey
>
>>
>> Robert Ramey
>
> _______________________________________________
> Boost-Testing mailing list
> Boost-Testing_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-testing