From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2003-02-14 11:30:07
David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
>> Hi Markus,
>>> any objections to applying the attached patch to
>>> vacpp-tools.jam? It allows to extend the toolset and overide
>>> the path to the compiler installation directory. It doesn't
>>> change anything if the compiler is in the default search path.
>>> I need this for runnning regression tests on the same machine
>>> for Visual Age 5 and 6 in one go.
>> This looks perfectly reasonble to me.
> Not to me.
Oops, already applied. :-(
> Extending a toolset to override installation directory requires
> that the directory be set as a variable "on" the target, or you
> will just end up with one global setting for installation directory
> and you'll just use *one* of the actual toosets (whichever one gets
> used to generate the last target). Try it with -n -a and inspect
> the command-lines to see what I mean.
I don't understand what you mean. I have been using this with two
toolsets (va5 and va6) which extend vacpp and just override VA_BIN to
genrate the regression tests and I can't find anything wrong with it.
How should it look like to be correct?
> I also worry a bit about the use of very generic global variable
> names which appear to be picked up from the environment (e.g. CXX).
They are set by bjam build flags and it has been like that for quite a
while now. IIRC, I asked on the list if this is ok.
> The philosophy for most toolsets has been to try to avoid relying
> on environment variables whenever possible. I think that this
> criticism applies to the current state of the toolset also.
Hmm, should I just rename the variables?
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