From: David Abrahams (dave_at_[hidden])
Date: 2007-05-22 10:53:28
on Tue May 22 2007, "John Maddock" <john-AT-johnmaddock.co.uk> 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 http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk