Boost logo

Boost-Build :

From: Ali Azarbayejani (ali_at_[hidden])
Date: 2003-03-17 10:20:51

Hi Vladimir,

I'm not sure why this developer has set template-depth=30, but it was
deliberate, so my assumption is that there's a reason. My goal is to
replicate the exact build of the existing system, including all compiler
flags, so I'm not asking why the flags are there but I'm asking if the
build system supports changing them (it ought to).

I would think that the best design philosophy for Boost.Build would be
to provide a good set of defaults (e.g. -Wall -ftemplate-depth-100), but
still allow complete control over these for the developer who wants or
needs to do so. Perhaps there should be a feature called
<cxxflags-default> which can be overridden for a particular target. Or,
perhaps, these are somehow initially part of the <cxxflags> value, but
this value can be subtracted from as well as being added to (currently
can only be added to).

As to creating feature "loose-warnings" or something like that, you
know, I think the approach of "feature normalization" is useful only to
a certain point...for the major conceptual actions of compilers (debug
symbols, optimization modes, etc) it is nice and useful to be able to
specify the behavior abstractly. But there are so many
compiler-specific flags that need to be controlled directly for the sake
of sanity, especially when dealing with ported code that wasn't
originally developed in your system. For example, MSVC allows disabling
particular warning numbers (GCC does not).

What I found in the design and evolution of my build system to be the
best policy covering both simple and complex projects is

(1) Provide good default CXXFLAGS
(2) Allow adding to CXXFLAGS, globally or toolset-specific
(3) Allow subtracting from or overriding default CXXFLAGS, globally or

I'll have more to say about this later, but for now, I've removed the
"-Wall" flag in from gcc.compile in my working copy as a work-around.

I am now having problems with command-line overflow due to the
"brute-force" way that Boost.Build generates command lines (super-long
path names, many duplicates). I am delving into how "generators" and
"properties" interact to find a work-around for this.

Thanks for your explanation,

Vladimir Prus wrote:
> Hi Ali,
> > In gcc.jam, this is the compile action
> >
> > actions compile
> > {
> > $(NAME:E=g++) -Wall -ftemplate-depth-100 $(OPTIONS) -D$(DEFINES)
> > -I$(INCLUDES) -c -o $(<) $(>)
> > }
> >
> > A project I am building requires having no "-Wall" (too many spurious
> > warnings) and -ftemplate-depth-30.
> >
> > Is there a principled way of dealing with this (other than modifying
> > gcc.jam)?
> Oh, for Boost "-Wall" makes most sense, and I strongly believe all warning
> should be enabled, so it was hardcoded. Seems like broader real world is not
> that simple. One obvious solution is to have feature "loose-warnings" or
> something. When set to true, it will suppress "-Wall".
> I think the name of feature should clearly indicate that something
> questionable is beeing done. "-Wall" is better for most projects, so let's
> devise a name that won't be used lightly.
> Does that look ok?
> Concerning "-ftemplate-depth" --- why do you need "30"? What problems "100"
> cause. Another feature will work, but I'm interested in some rationale.
> - Volodya


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at