Re: [v2] como support

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-31 15:23:54

Vladimir Prus <ghost_at_[hidden]> writes:

>> 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 ;
>
> Those proposals look reasonable to me.
>
>> 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 ;
>
> Probably, "configure gcc" should just search for "g++*" in PATH?

If that's a normal way to have it installed, then yes, I think it
should check for that (among other things). Like perhaps it should
also look for /usr/local/gcc-* as I described earlier.

>> >> 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.
>
> Probably, never tried though.

I note that WINE is not actually an emulator, it's a reimplementation
of the Windows API. Not sure if everything that CMD.EXE needs is
implemented, but it seems likely.

>> >> 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.
>
> Well, I've included that in "compiler startup overhead". To be exact, for 
> small files compiling with all costs included is very fast.

Given that it's not an emulator, I don't see why there should be any
significant cost.

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

I don't see any practical difference between your last 2 items,
'directory with the compiler, and 'full path to the compiler'.

>> What do you mean by "variables?"
>
> I mean "option" -- there are three possible way to configure a toolset, 
> and user must know which one is used for each specific toolset.

a. Not if we do it the same way for all toolsets (i.e. give the
installation directory, whatever that means for the particular
compiler).

b. I'm not sure that's so important anyway.

>> >> 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?
>
> Almost. I always though that "rephrase" is a process which changes
> the words, but retains the meaning. 

Technically, you are right. 

> From that, I concluded that "where installed" is exactly the same as
> "directory where the executable resides".

Understandable. I didn't mean to imply they were the same.

>> > 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?
>
> No, because of my confusing over the word "rephrase". I understand
> what you mean now.

Thanks.

>> 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.
>
> Ok, then priorities don't matter much ;-)

Unless, of course, people really don't need a prefix mechanism ;-)
But I think they do.

> We don't have an argument now.
>
>> then yes. 
>
> Recalling some of your syntax suggestions above, I think we can get a very 
> clear interface. With
>
> configure msvc : 8.0 : some_path/bin/cl ;
>
> you specify the path to the compiler binary
>
> configure msvc : 8.0 : root=some_path ;
>
> you specify installation root, and it's clear that you specify the root. With
>
> configure gcc : 4.0 : root=/opt/gcc-4.0 ;
>
> you again specify the root, and with
>
> configure gcc : 4.0 : root=/usr c++=g++-4.0 ;
>
> you specify root and a name of compiler binary.

I still can't understand giving compiler binaries special status.
Boost.Build is not going to be C++- or even compiler-centric, at least
not for much longer. And this sets up another thing to remember for
each (kind of) toolset: which binary in a given (kind of) toolset has
special status?

>> >> > 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.
>
> Maybe we can start with a fully general solution: user can override all the
> command line used by toolset with the exact command line. Hmm.. makes me
> wonder if this is implementable in bjam at all.

I don't think it's easy. The user would have to be able to induce
early target binding.

>> 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.
>
> That's semantically equivalent to 
>
> actions gcc.link
> {
> $(GCC-LINK-INVOCATION)
> }
>
> where GCC-LINK-INVOCATION has references to various variables. But, AFAICT,
> it's not possible in bjam -- the var references won't be recursively expanded.

That's one way to look at the problem. There's also the problem of
target binding.

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