Boost logo

Boost-Build :

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?

Markus

 


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