Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2007-05-22 10:53:28

on Tue May 22 2007, "John Maddock" <> wrote:

> David Abrahams wrote:
>>> Sure, but with a "generic" toolset that used CXX/CXXFLAGS etc to run
>>> an arbitrary compiler, we surely could support that?
>> What are you proposing gets done with platform/compiler-independent
>> build properties that are in existing Jamfiles? Do they just
>> disappear, or do they get translated into one person's idea of a
>> standard compiler flag? What does "support" mean in either case?
>> What do we tell people when their builds don't work?
> Dave, at present if the compiler is unsupported the user gets no help from
> us at all, the same issue exists with CMake and/or autotools - but at least
> those two give the users a sporting chance of compiling with their "unknown"
> compiler if they can figure out what CXXFLAGS to use.

I understand that.

> I'm suggesting we do the same thing.

We have different constraints. We don't have low-level build
descriptions as in Makefiles.

> Existing supported toolsets remain unchanged. The 99% case where
> the user is using a version of gcc but with custom invoke/compiler
> options could be detected (autoconf does this already) and forwarded
> to our gcc toolset presumably.
> I had meant to test this out by now, but you know time etc...

You're not answering my questions. What about the
platform/compiler-independent build properties when they appear in
Jamfiles? Are they ignored, or do they get translated somehow, or

FWIW, it was a design goal of Boost.Build v2 to get away from builds
that depend on environment variables.

Dave Abrahams
Boost Consulting

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