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

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-09-09 20:10:53

Andrei Melnikov wrote:
> 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.

In my experience that is rarely the case. Or to put it another way, of 
the many compilers I've used, I have yet to meet one that I did not have 
to change the vendor defaults. Not all of them of course, but by now 
I've gotten into the habit of checking all the option defaults to make 
sure they are what I want.

> A user should be able to choose between the two possible policies.

Why? What makes the vendors defaults any more special than the defaults 
the BBv2 toolsets specify?

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

But portable builds was one of the driving forces behind Boost Build. So 
why should we abandon it now?

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

Yes. And I tried with, for example, the gcc toolset in BBv1. We want to 
allow users to control the compilers portably, hence we want to provide 
BB features for all the compiler features.

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

No, but it will help others in reproducing a build. If you can't see how 
something was compiled it's impossible to reproduce. That's why I spent 
some time recently adding the display of response files to bjam.

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

That would be intractable. There is no way to define "reproducible" 
given that the context of how BB is being used changes for every one. It 
is not possible to account for all current use cases, let alone for all 
future use cases.

> In
> this case we will need an extensive set of tests, but we already have
> a test suite in place (Boost).

Boost makes for a poor build system test suite. It is tested in the 
narrow use case of CLI debug C++ programs only. There are innumerable 
other use cases.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo