Re: [boost] Boost building with CMake

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