Re: [v2] como support

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-24 11:31:07

Vladimir Prus <ghost_at_[hidden]> writes:

> Ick indeed. Ideally, the como toolset should compute all of the
> above command from c:/tools/como433/bin/como.exe and a separately
> passed path to vc7.

Actually it should use the vc7.1 toolset configuration. In other
words:

import msvc-config ;
using como : : backend=msvc-7.1 ;

should be enough.

> Now to your question about better way.
>
> I believe that in a large number of cases, the full path to compiler
> is enough to set up everything.

That doesn't make it the right thing to do.

> Yes, there are cases when it does not work.

That is not the problem. I am trying to make the point that what we
tell people about it in the documentation is misleading, and there's
no simple and understandable way to describe what we actually do. We
need to do something that's easy to document CORRECTLY and to
understand, both for toolset authors and for users. What we're doing
now is black magic, and there are no simple guidelines for either
toolset authors or for users that won't lead to confusion. A toolset
is not represented by a single command, and pretending that it is just
doesn't work. I'm sorry, but it's a hack that doesn't generalize.

> 1. In your case, V2 cannot really verify that the above command will
> work, and so issues pointless (in your case) warning.
>
> 2. If I want to build with visual C++ under Linux (using windows
> emulator), I don't want calling any setup scripts, I just want to
> call a single command that I provide.

An emulator shouldn't have any problems with the setup scripts.
What's wrong with the setup scripts under the emulator?

If the toolset needs setup script configurability, it should have an
option to disable setup:

using msvc : 7.1 : : setup="" ;

> We can handle this by using several modes of initialization:
>
> 1. If 'simple' mode, only compiler command is specified, toolset tries to
> figure out the rest.

It's not simple if it's hiding incomprehensible magic. Furthermore,
it's part of the build system's job to figure out what command to
invoke. I don't see how being asked to specify the command is simpler
than being asked to say where the toolset is installed, for the simple
case. At least in the simple case, chances are that all components of
the toolset are installed together. We can ask people to tell us
where the executables of the toolset are installed, for example.
Seems to me that

c:\Program Files\Microsoft Visual Studio\vc98\bin

is every bit as easy to find and understand how to specify as

c:\Program Files\Microsoft Visual Studio\vc98\bin\cl.exe

and it makes sense.

> 2. In 'advanced' mode, user can specify 'prefix' and 'suffix' commands
> that will be invoked before and after compiler. Consider:
>
> using gcc : 4.0 : g++-4.0 : <prefix>distcc ;

No more angle brackets, please!

I don't think "prefix" and "suffix" are enough. You might also need
to specify the link command, for example.

> How this prefix is combined with prefix added by toolset (again
> consider setup script for vc) is not yet clear.
>
> 3. In 'expert' mode, user passes the exact command line, which is used 
> verbatim, and no checking is performed by toolset.
>
> Will that cover all cases?

No, because: a toolset does not correspond to one command line, and
because you haven't got a system for specifying a command-line. You
can only specify a command. How will you deal with all the fragments
of the command that might be required at various points in the
command-line? And how will you write the rule actions to expoit them?

I also want to note that for Windows users, MSVC is invoked via

cl

and not

cl.exe

Nobody types the extension. Telling people they can write the command
and then complaining when you can't find "cl" is unfair. 

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com