Re: [Boost-build] [msvc] What to do with default options?

From: Andrei Melnikov (andy.melnikov_at_[hidden])
Date: 2006-09-09 19:20:22

On 07/09/06, Artem Alimarine <artem_at_[hidden]> wrote:
> Vladimir Prus wrote:
> > That's a bit different from what we do now -- there are some explicit defaults
> > for some options. I think for gcc, we increase the warning level a bit --
> > which is a good thing in my opinion.
>
> I did not mean that "default" should always translate to nothing. This
> would be a case when "default" translates to e.g. -Wall. The idea was to
> use "default" to pass the information, that the option was not
> explicitly specified by the user.
>
> >
> > Anyway, in the case when we want to pass -W3 to compiler, but -W3 is a
> > default, I'm not sure what to do. Not passing -W3 can lead to nicer command
> > lines, but then if compiler's default changes from version to version, we'll
> > need ever more toolset-version-dependent logic, which is generally hard to
> > get right.
>
> My idea was to rely on the compiler vendor for the defaults. I expected
> that it leads to less code in the build system because the compiler
> vendor in general knows better what to do by default. If a default value
> changes from version to version, you do not need to change the toolset
> unless you do not like the change.
>
> In my previous post I was thinking along the following policy:
> Call the compiler with the minimal required options. Do only what you
> are asked to do. Rely on the compiler defaults.

A user should be able to choose between the two possible policies. At
the moment neither of these policies is implemented.

Personally, I like this policy more, because I don't need portable builds.

> You propose basically another policy:
> Take full control. Nail down all the defaults and pass them to the
> compiler. Do not depend on the changes in the compiler.

This policy is impossible to follow in practice. How many options does
MSVC have? I bet GCC has even more options. Do you want to maintain a
list of all these options and their default values?

Also I don't think that displaying 50 options in a debug log instead
of just two will help to find an error in build configuration.

I think the best way is to pass as few options as possible. Just
enough to get reproducible builds on all versions of all toolsets. In
this case we will need an extensive set of tests, but we already have
a test suite in place (Boost). Also I think we should ship
Boost.Config with Boost.Build because this set of headers and macros
also helps to get portable builds.

Concerning debugging, I think we should display both logical BBv2
options (property set) and physical compiler options for each target.
Is this currently possible?
-- 
Andrei