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

From: Artem Alimarine (artem_at_[hidden])
Date: 2006-09-07 05:07:10

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.

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.

I am also wondering, what should be the policy for options like 
asynchronous exception handling (/EHa vs /EHs):
- Chose the most concervative option as the default (asynchrounous 
exceptions). This guarantees that the generated code is safe. However, 
most programs have no idea about asynchronous exceptions. It looks like 
usage of asynchronous exceptions is rather exceptional. The performance 
will suffer.
- Choose the typical usage as the default (synchronous exceptions). The 
programs that are not typical, i.e. that need /EHa, should use the 
explicit option.

It would be nice to have an explicitly stated policy for dealing with 
defaults. This is needed for both the users and the developers. For 
users to know what you get by default, for the developers to guide the 
implementation.

Artem