Re: [v2] como support

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-25 10:03:20

Vladimir Prus <ghost_at_[hidden]> writes:

> On Wednesday 25 May 2005 17:33, David Abrahams wrote:
>
>> > 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.
>
> By 'command' I meant a single command -- i.e an binary name with an
> optional path. I'm not trying very hard to defend the "distcc g++"
> trick.

Then we need to be very explicit about that. 

>> 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.
>
> Joe Developer probably has just a single compiler, in which case plain
>
> using msvc ;
>
> is likely to work.

That's true.

>> 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.
>
> Yes, we need to provide separate control over
> compiler/linker/whatever names. But it's would be clumsy to write:
>
> using gcc : 4.0 : /usr : compiler-name=g++-4.0 ;

I would expect that to be

using gcc : 4.0 : c++-compiler=g++-4.0 c-compiler=gcc-4.0 ;

or maybe even

using gcc : 4.0 : c++=g++-4.0 c=gcc-4.0 ;

or, if allowed to fantasize about syntax, something like

configure gcc-4.0 : c++=g++-4.0 c=gcc-4.0 ;
configure gcc-4.0 : c++=g++-4.0 c=gcc-4.0 root=/usr ;

or, even more ideally, if the case where your executable names are
just the same as the standard ones with your version suffix is really
common, just

configure gcc-4.0 ;

Note that this setup step is going to be the biggest hurdle for new
users.

> Maybe we should figure out the interface for all other configuration options
> (prefix/sufix/exact command line) first.

That might be a good idea.

>> >> 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.
>
> I don't have the slighest idea if running "cmd.exe" with a command
> will work.

Seems like it should, if you really have an emulator.

>> BTW, you start an emulator up for each object file? What emulator is
>> this? Is it fast? I might like to try it.
>
> I did not try anything real with msvc, because of that 'call' issue. I do 
> regularly use some other compiler, though, and the overhead to start the
> compiler is not noticable. 

It's the overhead of starting the emulator I'm curious about.

> The files are small to compile time never was an 
> issue. The emulator is wine (http://winehq.com). I'd recommend getting the
> most recent version there is.

I've heard of it. Will look.

>> >> 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.
>
> Let me recall that in V1, there's another notion, "installation
> root", and I think that for msvc that the directory that contains
> "bin", "lib" and "include" directories. So this gives three
> variables -- 'install root', 'directory with the compiler, and 'full
> path to the compiler'.

What do you mean by "variables?"

>> 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" , 
>
> I'm completely lost. Above you say that "where installed" =
> directory where the executable resides. 

No, I was saying I *could* rephrase that way if you insisted, BUT
here is my argument against doing that. Do I make myself clear?

> Now you say that "directory of the executable" is much worse that
> "where installed". Isn't this the same? 

Well, no, they're not the same in the general case, as you can
understand by the use of --prefix=/usr/local/gcc-x.y.z with the
executables in /usr/local/gcc-x.y.z/bin where the installation
directory is /usr/local/gcc-x.y.z as described below. Was that
unclear from what I wrote below?

> Or you talk specifically about *saying" and mean that one *term* is
> better then the other.
>
>> 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.
>
> I enjoy whatever setup Debian has. I believe that incompatible versions of
> libstdc++ have different 'soname's, and so can happily coexist in the same 
> LD_LIBRARY_PATH.

Well, I (and many others) commonly acquire specific versions of GCC by
compiling from source and using their standard install procedure; it
doesn't seem to do that.

>> 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 :)
>
> I agree that if there's a clean way to specify prefix to the command, then
> "distcc g++" as the command should be removed.

I see the priorities differently. First "distcc g++" as the command
should be removed because it's misleading. Then if people need a
prefix mechanism, we should give it to them. But either way, both
will get done at once.

>> 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.
>
> Ok, and this boils our argument to whether we should be specifying, for
> the case of standard toolset name
>
> using msvc : 8.0 : some_path ;
> 
> or
>
> using msvc : 8.0 : some_path/cl ;
>
> Right?

If we no longer have an argument over what we *tell* people they can
specify (i.e. saying "the command" is unacceptable), then yes.

>> 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."
>
> I suppose we can allow the user to specify either the compiler path, or 
> directory where compiler is present, or "installation root" directory, 
> and guess what he meant by checking for compiler's presense.

I'm against too-tricky guessing. Feels Perl-like to me. Also,
it will require very complicated diagnostics:

"looked for foo/bar/baz, assuming you meant foo to be the
installation root, looked in foo/baz, assuming you meant foo to be
the compiler installation directory, and found that "foo" itself is
not executable, assuming that you meant it to be the toolset
invocation command."

It will also require complicated documentation.

>> > 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.
>
> Yea, those would go after $(COMPILE-COMMAND) and before $(SUFFIX)

So prefix and suffix are the same for each action in the toolset,
while COMPILE-COMMAND et. al give you control over individual
commands? 

Well, it's fine, but I'm concerned that it might be premature
generalization that doesn't quite accomplish full generality. For
example, if you need parens around the entire link command (for some
reason) *only*, you can't get there from here.

If you're sure that some people need all of the generality you're
describing *and* the people you know of don't need any more
generality, I'm okay with it I guess.

Ultimately I'd prefer something more
akin to a Python format string that lets you drop in the compiler
options, something like

gcc:invocation="distcc %tool %options > log"

which might get expanded into 

distcc g++ ...options-here... > log

with the ability to specify, e.g.

gcc:c++="distcc g++-4.0 %options 2>&1 > log"

which would override the normal gcc invocation, and

c++-tool=g++-4.0

which would only override the %tool element of the gcc command.

But that may be beyond our reach right now.

>> > 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?
>
> No, the command to invoke the linker will be guessed from the compiler 
> command.

I'm sorry, I mean, you specify COMPILE-COMMAND, PREFIX, and SUFFIX.

>> > 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."
>
> And if we say that this 'command' should be executable name with optional 
> path, and no shell magic is allowed?

Much less odious, but I'm still not happy with it because, e.g., of
the arguments about the way gcc installation goes given in my last
message.

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