Re: [Boost-build] msvc express toolset.

From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-08-03 06:56:21

   Hi Steven

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

   *nod*, but I believe it 'appearing to work' in this configuration is 
a defect.

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

   I'll look into it. Although, I do not really know what this 'compiler 
version' could be used for.

   My initial guess is to just name this toolset 'msvc-environment' (or 
something similar) and have the 'user be ware' that the next run may not 
have the same environment setup and Boost Build will have no way of 
detecting this.

   We could display the detected tool version in case of 
--debug-configuration or something similar.

   Come to think of it now - here we actually have many tools in this 
toolset and each might theoretically have its own independent version 
information :-). Not sure we should do much about this though until 
someone explicitly requests it...

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

   Well, we just run it by its name and we 'hope' something gets called. 
:-) For instance, Windows has some extra path information stored in the 
registry that is not part of the PATH environment variable. There might 
be others as well. I guess this is just a fallback case to 'we hope the 
environment somehow knows what to do about this'. :-)

   Anyway... I'll go play with this some more now...

   Best regards,
     Jurko Gospodnetić