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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-06-02 09:13:37

On Wednesday 01 June 2005 00:23, David Abrahams wrote:

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

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

I might try one day.

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

Some API functions might be implemented in suboptimal way, for example. But 
anyway, since neither of us tried VC under WINE, this all is theories.

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

full path to compiler includes all name of the binary.

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

Agreed.

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

I'm probably biased, but here are my reasons:

1. I find "some_path/bin/g++-4.0" nicer that
"root=some_path/bin c++=g++-4.0"

2. I find "g++-4.0" nicer then "c++=g++-4.0"

3. I don't want to change configure syntax in an incompatible way.
If we introduce explicit "root=" syntax, the current syntax can
stay.

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

What do you mean?

- Volodya

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