From: David Abrahams (dave_at_[hidden])
Date: 2005-04-29 08:57:38
Vladimir Prus <ghost_at_[hidden]> writes:
> On Thursday 28 April 2005 19:40, David Abrahams wrote:
>> Vladimir Prus <ghost_at_[hidden]> writes:
>> > 1. Configure gcc with
>> > using gcc : : "distcc g++" ;
>> This whole business of specifying the command to use and making other
>> deductions from there is a fragile hack at best. Some toolsets throw
>> out the last path element and compose new paths from there. Writing
>> "foo/bar/distcc g++" is going to produce unpredictable behavior in
>> these cases. We need a better solution.
> Can't we settle on specific format for "compiler command"?
We can if we document it; so far we seem to make un-fulfillable
promises that you can write anything there as long as it can be
followed by flags. In order to do the hacks we're doing with it,
we're going to end up documenting that it's nothing more than a path.
Also, unless things have changed, we falsely imply that the command
you write there will always be used verbatim. In those tools where
the last path element is thrown out and replaced, it doesn't work that
way. Furthermore, some toolsets use of several different commands:
look at GCC, which, when compiling 'C' code, should never use "g++."
It also doesn't use "g++" when linking static libraries. This
convention just doesn't scale.
> Few toolsets care about the content, and those that care expect that
> the last element is the name of compiler. Formalizing that in docs
> should be OK.
I don't think so. I don't think you can specify it in a way that's
accurate, scalable, and easily understood.
> In testing.jam, I'm trying another approach -- the tested command is
> not run directly, but via
> $(LAUNCHER) $(COMMAND)
> so you can do
> bjam --v2 testing.launcher=valgrind
> This can be generalized to all toolsets, but seems like a lot of
> work with no apparent benefit.
Maybe so, but I don't see how the current system can work.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
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