Boost logo

Boost :

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
> > at my disposal. Unfortunately, things don't work with
> > <boost/stdint.h>. This include results in the following
> > error:
> First of all, it might be a good idea to make a new mingw-tools.jam
> 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

> > gcc-C++-action ..\src\bin\gcc\debug\runtime-link-
> > 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
> > do you add flags such as this to the commands in the Jamfiles? I
> > modified gcc-tools.jam changing actions gcc-C++-action, which
> > 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
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at