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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-05-31 10:17:28

On Wednesday 25 May 2005 19:03, David Abrahams wrote:

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

Sure.

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

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?

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

Probably, never tried though.

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

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

I mean "option" -- there are three possible way to configure a toolset, 
and user must know which one is used for each specific toolset.

> >> 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. From that, I concluded that "where installed" is 
exactly the same as "directory where the executable resides".

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

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

Ok, then priorities don't matter much ;-)

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

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

I'm not very fond of my proposal too.

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

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

- Volodya

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