Re: [boost] Re: Boost.Threads, the Boost.Build system and GCC

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-06-06 11:15:43

----- Original Message -----
From: <williamkempf_at_[hidden]>

> 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.

None in particular.

> > 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.

In what sense, overkill? Features not relevant to particular compilers never
cause subvariant directories. Certainly something equivalent to -ansi
pedantic is something that we have for many compilers. What did you have in
mind?

Features like this one might make it worth revisiting an earlier idea I had
of being able to specify that some simple features are "link-compatible",
i.e. that variation in their values don't cause distinct subvariant targets
to be formed. Because gcc doesn't support #pragamas for turning things like
this on and off, it might be neccessary to have a mechanism for saying that
particular source files must be compiled with a slightly different feature
set. One approach might be to say that these files should be made into
distinct static libraries.

> 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.

We'll see some failings soon enough, I'm certain of it ;-/.

-Dave