Re: [jamboost] Re: [v2] como support

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-05-25 01:46:02

On Tuesday 24 May 2005 20:31, David Abrahams wrote:
> 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.

Point taken.

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

Uph.. I though I understood your objections to this scheme, by now you've
lost me again.

Clearly, you should be able to specify
1. The name of compiler binary
2. The path to the compiler binary

This together means that you should be able to specify full compiler filename,
like /usr/opt/llvm-g++ and have things work. This leads to a simple rule:
you specify the command that invokes the compilerr.

With msvc, the compiler name is almost always the same. But, for consistency 
sake, I decided that you still should provide the command. Otherwise, you'd 
have to remember that for msvc and borland you should provide path (without 
compiler name), and for other toolset you must provide command (path + 
executable name). 

For compilers like msvc, this means that toolset essentially throws away the
executable name part, but I think it's better then having different user 
interface for initialization of different compilers.

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

Heh? I don't think that "call" is a valid command under Unix, and that's what 
stock action contains, verbatim.

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

Because "where installed" is not that clear itself. On my system, all versions
of gcc are in /usr/bin. Clearly, passing /usr/bin won't say anything about
which version I need. Passing /usr/bin/g++-2.95 is absolutely clear.

And again, specifying command for one toolset and some "install root" for 
other is incomprehensible *for users*.

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

Except that it does not generalize to non-Windows systems. Yes, cl.exe is
not strictly necessary above, but it's better than different rules for 
different toolset.

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

Ok.

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

Ok, and that too.

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

Well, th rules will look like this

action .compile
{
$(PREFIX) $(COMPILE-COMMAND) $(SUFFIX)
}

action .compile
{
$(PREFIX) $(LINK-COMMAND) $(SUFFIX)
}

In expert mode, you'll specify values COMPILE-COMMAND and LINK-COMMAND
and PREFIX/SUFFIX will be left empty.
In advanced mode you will specify COMPILE-COMMAND (just compiler command, like
/usr/bin/g++-2.95) and specify PREFIX/SUFFIX yourself.
In simple mode, you will specify COMPILE-COMMAND and prefix/suffix will be
computes automatically.

What's wrong with that?

- Volodya

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

Noted.

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2