Re: Boost.Threads, the Boost.Build system and GCC

From: williamkempf_at_[hidden]
Date: 2001-06-06 10:42:26

--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> 
> ----- Original Message -----
> From: <williamkempf_at_h...>
> 
> 
> > I've been trying to get the jamfiles included in the latest
> > Boost.Threads upload to work with GCC (mingw32), the other 
compiler
> > at my disposal.  Unfortunately, things don't work with
> > <boost/stdint.h>.  This include results in the following 
compilation
> > error:
> 
> First of all, it might be a good idea to make a new mingw-tools.jam 
file
> based on gcc-tools.jam. I am not familiar with mingw, but gcc-
tools.jam is
> really designed to do Cygwin and linux builds. I'm not sure if the
> requirements for mingw are sufficiently different.

Probably not, but if I find them to be all break them out as you 
suggest.

> > gcc-C++-action ..\src\bin\gcc\debug\runtime-link-
dynamic\condition.obj
> > In file included from ..\src\..\boost\thread\xtime.hpp:21,
> >                  from ..\src\condition.cpp:19:
> > c:\boost\boost\stdint.h:73: parse error
> > c:\boost\boost\stdint.h:81: #error defaults not correct; you must
> > hand modify bo
> > ost/stdint.h
> >
> > Looking through the archives here there's a mention that -ansi -
> > pedantic options should correct this.  So the first question is 
how
> > do you add flags such as this to the commands in the Jamfiles?  I
> > modified gcc-tools.jam changing actions gcc-C++-action, which 
works
> > but is obviously not the "correct" way to do something like this.
> 
> It's not completely obvious to me. Don't we want to compile all 
boost code
> with -ansi -pedantic?

I honestly don't know.  I'm not a GCC user, really.  Since you didn't 
have these options in gcc-tools.jam to begin with I assumed there was 
a reason for it.
 
> If not, it sounds like a new simple feature definition is in order 
(see
> features.jam). I think you'd want to put a default value for it in 
all of
> the variant definitions so that subvariant directories were not 
created when
> the feature has its default value.

I'm wondering if there should be a generic way to specify compiler 
options instead of requiring specific features?  It seems like there 
may be some options that are specific to individual toolsets for 
which a feature would be overkill.

BTW, none of this is meant to point out failings in the 
Build.System.  So far I see none.  I'm just trying to figure out how 
to do some of the more advanced things that aren't (at least 
currently) included in the base rules.

Bill Kempf