Re: [v2] como support

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-25 08:33:46

Vladimir Prus <ghost_at_[hidden]> writes:

> On Tuesday 24 May 2005 20:31, David Abrahams wrote:
>> Vladimir Prus <ghost_at_[hidden]> writes:
>>
>> 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. 

Yes, that's fine for toolsets that are represented by a single primary
executable, as most compilers are.

> This leads to a simple rule: you specify the command that invokes
> the compilerr.

No, that's not fine. It leads to things like

/usr/funkybin/distcc g++

or

/usr/bin/g++ -mmipspro

which don't work, except in half-baked ways and only with particular
toolsets. Any toolset that needs to deduce the directory where the
compiler actually resides will choke on those constructions.

> With msvc, the compiler name is almost always the same. 

As it is with most compilers.

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

I understand that decision, but I think it came in part from trying
too hard to fit all the configuration into a single argument, and in
part from the presumption that it's very common to want to use
compilers that are installed with nonstandard executable names. I
know you and I do that all the time, but I don't think Joe Developer
does.

Another possibility would have been to ask people to provide specific
and separate arguments for the compiler name when it is other than the
default. Ultimately you have to give them flexibility to rename
specific components of the toolset (e.g. the linker) independently
anyway, so that approach would scale up in a more consistent and
uniform manner.

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

Well, c'mon: we really shouldn't throw it away if we ask people to
specify it. After all, the same arguments you give for wanting to
customize the executable invoked for other toolsets apply here too.

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

I thought you were going to run the whole action under an emulated
command shell. That's what I'd do if I really wanted to run toolsets
designed to work under windows.

BTW, you start an emulator up for each object file? What emulator is
this? Is it fast? I might like to try it.

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

I think it's pretty clear. If you insist, I could rephrase and say:
"the path to the directory where the toolset's primary executable
resides." For toolsets like g++, msvc, etc., the primary executable
would be the compiler. 

For compilers like g++, for which it's very common to have to specify
a nonstandard path, specifying the directory of the executable is much
worse than saying "where installed" , because it's very common to
configure gcc-x.y.z with --prefix=/usr/local/gcc-x.y.z and install
without making aliases in /usr/bin. When you do that, you get a
little tree in /usr/local/gcc-x.y.z with subdirectories bin, include,
info, lib, libexec, man, and share. In that case, your g++ is called
/usr/local/gcc-x.y.z/bin/g++. 

Even if you do make an alias for gcc-x.y.z in /usr/bin, you still need
to add /usr/local/gcc-x.y.z/lib to LD_LIBRARY_PATH when linking and
running programs built with that compiler. If you don't install with
--prefix= OR if you put /usr/local/gcc-x.y.z/lib in your
LD_LIBRARY_PATH permanently you *will* break the functioning of your
other versions of g++, and sometimes break existing programs that are
expecting to find libstdc++.so from those other versions. That has
been my experience, and it's consistent with the advice you'll get
from the GCC documentation on building/installing. 

If it's possible to establish multiple side-by-side versions of g++ in
the PATH (with different names, of course), but not requiring any
special environment setup before use, I'd love to know how. I guess
you can make /usr/bin/gcc-x.y.z a shell script that forwards its
arguments? Is it hard to get quoting right if you do that? That's
not done by the default gcc install procedure, BTW.

On the other hand, if you say "where installed" it's pretty obvious
that it means whatever you provided for --prefix=..., and then the BB
toolset knows where to find the lib/ directory (by default, of
course).

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

Yes, what's unclear is the instructions we're giving to users about
what to pass: when you say "the command" and then also give examples
like "distcc g++", you're headed down a road to doom :)

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

I never suggested we do it that way, and I never would.

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

Of course it does, as long as there's a way to specify the executable
name separately -- which of course we'd want to support for Windows as
well.

> Yes, cl.exe is not strictly necessary above, but it's better than
> different rules for different toolset.

I never suggested we do it that way, and I never would. In fact,
"different rules for different toolsets" is what we have today, only
we don't tell people we have different rules. Some toolsets (gcc) let
you specify a command. Others really only work if you specify an
executable path.

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

And, IMO, that should be congruent to the way the compiler command is
specified. I'm not sure it makes sense to make the compiler
executable "special." That makes the whole thing harder to explain,
because other toolsets have multiple executables, too. So then people
have to read the general explanation that you specify "the primary
executable" and learn that for most toolsets, that's the compiler,
instead of just dealing with the installation directory.

I believe any ambiguity over what "the installation directory" means
can be handled nicely with documentation and diagnostics. For
example:

Toolset msvc-6.0 couldn't find executable "Bin\cl" in
the specified installation directory, "c:\Tools\MSVC". The
default installation directory for msvc-6.0 is "c:\Program
Files\Microsoft Visual Studio\VC98". Please specify a
msvc-6.0 installation path that contains an executable called
"cl" in a subdirectory called "Bin." 

All of that text can be generated generically for every toolset, given
some standard rules, like:

toolset.default-installation msvc-6.0 : "C:\Program
Files\Microsoft Visual Studio\VC98" ;

toolset.find-executable user-specified-install-path : Bin\cl ;

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

Sorry, I don't get it. Normally there are options like -Ddefines and
-Iincludes that need to be embedded in the commands somehow.

> In advanced mode you will specify COMPILE-COMMAND (just compiler command, like
> /usr/bin/g++-2.95) and specify PREFIX/SUFFIX yourself.

So you specify everything in advanced mode?

> In simple mode, you will specify COMPILE-COMMAND and prefix/suffix will be
> computes automatically.
>
> What's wrong with that?

Only what I've said earlier about the problems with telling people
they can write "the command to invoke the compiler."

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