Re: [Boost-build] msvc express toolset.

From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-07-22 23:04:48

   Hi Steven.

>   I removed the problem in my sandbox but it seems that the msvc toolset 
> has been written so that it attempts to use the 'cl.exe' compiler 
> command directly without any setup script in case it can not recognize 
> the toolset version and simply expect the external environment to be 
> already correctly set up.

   OK, here's some more 'thinking out loud'. :-)

   First thing that confused me in the code was that if you specify a 
command or it is auto-detected then Boost Build will try to run a 
corresponding environment setup script before each tool command. But if 
you do not specify a command and it is not auto-detected then Boost 
Build will not run any environment setup script before each tool command 
and will instead expect all such tools to be accessible directly in the 
environment (i.e. be on the path).

   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.

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

   And now for the potential toolset choosing algorithm:

     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.

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

     3. If we have some explicitly defined or auto-detected toolset 
versions:
         3.1. If user requests one of the defined toolset versions we 
simply use that one.
         3.2. If user requests the default version we give him the 
first/best toolset version on the list.

   If a user wants to use some sort of a toolset version that expects 
its tools in the current environment's PATH - he/she can still do it by 
defining such a version explicitly in some .jam file or he can ask for 
the default one when there has been no version defined or auto-detected.

   If we do it this way I think the behaviour is clean and you get your
error/warning. The only thing that changes is that the code no longer 
behaves as it seems to have been intended to when user specifies an 
incorrect toolset version, but that does not matter as that case was 
producing a syntax error anyway.

   What do you think?

   I think the algorithm above solves all the problems except for that 
configuring/using topic you opened in the other part of the thread. That 
seems like a bigger subject as currently we use the toolset.using rule 
for 'configuring' toolsets while internally Boost Build marks toolsets 
as 'used' once the toolset.using rule is called for them. I guess 
something is 'doing too much' here. At first glance this seems like it 
will require splitting the toolset 'init' rule into 'init/configure' and 
'use' where use 'init/configure' will set up the version configuraiton 
while 'use' will do all the verifications...  but I'll have to think on 
this when I get some rest... way too late/early for me now... :-)

   Best regards,
     Jurko Gospodnetić