Boost logo

Boost-Build :

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ć


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk