Re: [Boost-build] [boost] [1.35.0] Threads - build failure using gcc on Win XP

From: Mat Marcus (mat-lists_at_[hidden])
Date: 2008-04-17 17:03:30

On Thu, Apr 17, 2008 at 12:56 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:
> Mat Marcus wrote:
> > For example, why is it necessary to view cygwin as an OS in the boost
> > thread jamfile?
>
> In general BB, and Boost in general afaik, views Cygwin as an OS.
> Because it is emulating Unix on Windows. Hence earlier comments about
> how this could be considered a cross-compiler situation.

Interesting. I see cygwin as providing a shell, a compiler, and a
bunch of useful utilities that enhance my windows OS experience. I
keep cygwin-provided tools in my path, regardless of which shell I
happen to be using. Of course the awkward part about using the cygwin
bash shell and some of the cygwin tools is that it a different
convention is used for pathnames. Which brings up an aside: Ideally,
when configuring a toolset, I'd like to be able to specify the path
convention required by the tool, independently from how bjam was
compiled. Is this possible today? If I recall correctly, last time
that one of my colleagues we tried to use boostbook there were some
issues in this area.

> > That is, why isn't it possible to determine default
> > choices for threadapi by dispatching on the toolset perhaps together
> > with something like the <toolset-gcc:flavor> property?
>
> Yes, that is the solution I was going to implement. Adding a flavor for
> cygwin is easy enough... But auto-detecting may not be. Help on figuring
> out a way to tell that the particular g++ is a cygwin flavor is
> appreciated. (Especially since I don't have cygwin)

That's a good question, and I also may not be the right person to ask,
since I don't have mingw. Here's what I can say. I use a menagerie of
gccs including: the cygwin-supplied gcc-3.4.4, sometimes a later
'experimetal' cygwin-supplied 4.x gcc, hand-compiled gcc 4.2 and 4.3,
various hand-compiled conceptgcc and some gccs compiled by others. As
far as I can see, the only thing that members of this collection have
in common is the vague notion that they are toolsets using 'unix-like'
artifact-naming conventions.  I use them from various shells and from
an msvc-built bjam (especially now that I can no longer build bjam
using any of them). From my perspective, mingw might be the odd man
out, and so I would turn the question around to ask whether mingw had
some tell-tale marks that would allow its auto-detection. In other
words, the only real help that I can offer is to suggest that we might
consider supporting arbitrary non-mingw gccs, rather than just the
particular gcc that happens to have shipped with cygwin.

 - Mat