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