[build] adding a rquirement for Cygwin only?
Is it possible to add, for example, <threadapi>pthread to a project's requirements, but only for Cygwin? This works: <toolset>gcc,<target-os>windows:<threadapi>pthread but it also applies to MinGW. This only applies to MinGW: toolset-gcc:flavormingw:<threadapi>pthread but Cygwin has no <flavor>. This: <toolset>gcc,<target-os>windows:<threadapi>pthread toolset-gcc:flavormingw:-<threadapi>pthread doesn't work. There are references to <target-os>cygwin in gcc.jam, but <target-os> is actually 'windows'.
AMDG On 01/19/2015 09:34 AM, Peter Dimov wrote:
Is it possible to add, for example, <threadapi>pthread to a project's requirements, but only for Cygwin?
This works:
<toolset>gcc,<target-os>windows:<threadapi>pthread
but it also applies to MinGW.
This only applies to MinGW:
toolset-gcc:flavormingw:<threadapi>pthread
but Cygwin has no <flavor>.
This:
<toolset>gcc,<target-os>windows:<threadapi>pthread toolset-gcc:flavormingw:-<threadapi>pthread
doesn't work.
There are references to <target-os>cygwin in gcc.jam, but <target-os> is actually 'windows'.
The correct <target-os> for Cygwin should be cygwin, not windows. The problem is that target-os is not auto-detected and defaults to being the same as host-os. In Christ, Steven Watanabe
Steven Watanabe wrote:
The correct <target-os> for Cygwin should be cygwin, not windows. The problem is that target-os is not auto-detected and defaults to being the same as host-os.
Thanks, but this doesn't solve my problem. What I think you're saying is that I should pass target-os=cygwin. But I can't do that in my use case, which is going into a library's test directory and typing b2 toolset=clang,clang-cxx11,gcc,gcc-cxx11,msvc-8.0,msvc-10.0,msvc-11.0,msvc-12.0 When a test depends on Boost.Thread, it tries to build it, and that fails on Cygwin. I could split the above into two lines, but it would've been nice for Cygwin to work out of the box with Boost.Thread. This is why I've been trying to come up with a way to change Boost.Thread's Jamfile to use <threadapi>pthread on Cygwin and the default <threadapi> on MinGW.
On Thu, Mar 5, 2015 at 10:37 AM, Peter Dimov
Steven Watanabe wrote:
The correct <target-os> for Cygwin should be cygwin, not windows. The problem is that target-os is not auto-detected and defaults to being the same as host-os.
Thanks, but this doesn't solve my problem. What I think you're saying is that I should pass target-os=cygwin. But I can't do that in my use case, which is going into a library's test directory and typing
b2 toolset=clang,clang-cxx11,gcc,gcc-cxx11,msvc-8.0,msvc-10.0, msvc-11.0,msvc-12.0
When a test depends on Boost.Thread, it tries to build it, and that fails on Cygwin.
I could split the above into two lines, but it would've been nice for Cygwin to work out of the box with Boost.Thread. This is why I've been trying to come up with a way to change Boost.Thread's Jamfile to use <threadapi>pthread on Cygwin and the default <threadapi> on MinGW.
Use the Predef configure support perhaps http://tinyurl.com/q8yjzmo ? import path-to-predef-src/check/predef : check require : predef-check predef-require ; exe my_special_exe : source.cpp : [ predef-check BOOST_OS_CYGWIN : <threadapi>pthread ] ; -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
AMDG On 03/05/2015 09:37 AM, Peter Dimov wrote:
Steven Watanabe wrote:
The correct <target-os> for Cygwin should be cygwin, not windows. The problem is that target-os is not auto-detected and defaults to being the same as host-os.
Thanks, but this doesn't solve my problem. What I think you're saying is that I should pass target-os=cygwin. But I can't do that in my use case, which is going into a library's test directory and typing
b2 toolset=clang,clang-cxx11,gcc,gcc-cxx11,msvc-8.0,msvc-10.0,msvc-11.0,msvc-12.0
When a test depends on Boost.Thread, it tries to build it, and that fails on Cygwin.
I could split the above into two lines, but it would've been nice for Cygwin to work out of the box with Boost.Thread. This is why I've been trying to come up with a way to change Boost.Thread's Jamfile to use <threadapi>pthread on Cygwin and the default <threadapi> on MinGW.
Last time I used Cygwin (which was admittedly a long time ago) I put something like this in my user-config.jam: import toolset ; using gcc ; toolset.add-requirements <toolset>gcc:<target-os>cygwin ; You could also split the command line arguments like this: b2 toolset=msvc-8.0,msvc... toolset=gcc/target-os=cygwin Actually... I seem to recall that Boost.Thread's Jamfile doesn't work correctly even if target-os is set. It sets the default threadapi entirely based on the host. In Christ, Steven Watanabe
Steven Watanabe wrote:
Last time I used Cygwin (which was admittedly a long time ago) I put something like this in my user-config.jam:
import toolset ; using gcc ; toolset.add-requirements <toolset>gcc:<target-os>cygwin ;
This would work if the only gcc on my system were Cygwin, and I probably could live with it, but it won't work in the case in which I also have MinGW and what gcc is used depends on the current PATH. Which is why I was somehow trying to make it autodetect.
Actually... I seem to recall that Boost.Thread's Jamfile doesn't work correctly even if target-os is set. It sets the default threadapi entirely based on the host.
That's probably because nobody ever sets target-os. :-) (There are other places that don't handle cross-compilation properly, using host-os when target-os would be correct. Most people are probably entirely unaware of the distinction. I admit I was.)
AMDG On 03/05/2015 11:08 AM, Peter Dimov wrote:
Steven Watanabe wrote:
Last time I used Cygwin (which was admittedly a long time ago) I put something like this in my user-config.jam:
import toolset ; using gcc ; toolset.add-requirements <toolset>gcc:<target-os>cygwin ;
This would work if the only gcc on my system were Cygwin, and I probably could live with it, but it won't work in the case in which I also have MinGW and what gcc is used depends on the current PATH. Which is why I was somehow trying to make it autodetect.
It takes a bit of hacking to make MinGW and Cygwin coexist. I know I did it once upon a time, but I don't remember the details. Autodetection would be great, but doing it right will probably be a fair amount of work.
Actually... I seem to recall that Boost.Thread's Jamfile doesn't work correctly even if target-os is set. It sets the default threadapi entirely based on the host.
That's probably because nobody ever sets target-os. :-)
(There are other places that don't handle cross-compilation properly, using host-os when target-os would be correct. Most people are probably entirely unaware of the distinction. I admit I was.)
In Christ, Steven Watanabe
participants (3)
-
Peter Dimov -
Rene Rivera -
Steven Watanabe