Re: [Boost-build] msvc express toolset.

From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-07-23 00:00:16

AMDG

Jurko Gospodnetić wrote:
>   Should MSVC not honor the <setup> properties and run appropriate 
> environment setup scripts even in case no command has been specified 
> or auto-detected? I think so. But currently it does not.

If a <setup> property is specified, then I suppose that the script ought
to be run.  Otherwise, it seems ok to assume that since the compiler was
found in the PATH everything else will be too.  I could go either way.

>   Looking through the code I see now another bug in the msvc toolset, 
> or perhaps in the common.jam module related to all the toolsets. In 
> case user specifies an invalid command for an already auto-detected 
> toolset version the new command will be appended to the list of 
> auto-detected properties. Then reading the command from the property 
> set will cause Boost Build to return multiple commands. Then passing 
> this 'list of commands' to common.jam's 
> get-invocation-command-nodefault rule will incorrectly detect that the 
> command is correct because its check-tool rule finds it ok if the 
> first or the last command in the list is ok!?

Yuck.  I think the reason that common.check-tool looks at the
first and last commands is to handle cases like this (from como-win.jam):

#   using como-win : 4.3 : "set COMO_BCC_INCLUDE=C:/include &&" como.exe ;

>     1. If user explicitly requests a toolset version which has not 
> been explicitly defined or auto-detected - we should report an error 
> as you requested. Note that this should not even attempt to check for 
> the tool on the current PATH.

This seems reasonable.  However, at present it does work if the
compiler is in the PATH, so this is a potentially breaking change.

>     2. If we have no auto-detected and no explicitly defined toolset 
> versions and user requests the default version we define a new 'hope 
> for the best' toolset version named 'default' by:

Could we run the compiler and parse its output to find the version
like the gcc toolset does?

>         2.1. If the default compiler executable exists on the PATH - 
> we decide which environment setup scripts to use based on that 
> compiler's location.

ok.

>         2.2 If the default compiler executable can not be found on the 
> PATH - we do not use any environment setup scripts and simply hope 
> that each of the tools used will be directly available in the environment.

If the compiler isn't in the PATH and we don't use any setup scripts,
how is anything going to work at all?

>   What do you think?

It sounds good to me.

> ...except for that configuring/using topic you opened in the other 
> part of the thread. At first glance this seems like it will require 
> splitting the toolset 'init' rule into 'init/configure' and 'use'

Alternately, init can leave the tool in an error state with a message to be
printed if it's actually used.  Then there's the question of when exactly
the error should fire.  A safe point would be in the rule associated with
the updating action.  For example in msvc.compile.c and msvc.compile.c++.

In Christ,
Steven Watanabe