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 what? 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