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.
> > 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
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
> > 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?
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk