From: Sean Huang (huangsean_at_[hidden])
Date: 2006-08-30 12:09:18
----- Original Message -----
From: "Stefan Slapeta" <stefan_at_[hidden]>
Sent: Wednesday, August 30, 2006 10:09 AM
Subject: Re: [Boost-build] Intel and vc8
> To achieve this, another solution is possible that has my vote (but it
> maybe has side effects):
> Don't call iclvars.bat before invoking the compiler
I agree that iclcars.bat should not be used until Intel fixes iclvars.bat to
accept VC version parameter. (we have VC7.1, VC8, IC7.x-9.x on the same
machine and need to build combinations of them). Also to avoid warnings of
inconsistant /Qvc options (specified on the command line is different from
the one in the icl.cfg), it is probably a good idea to create a separate
cfg file and set ICLCFG accordingly.
> Call the right vcvars32.bat based on the value of 'compatibility'. Set
> additional intel paths (this would be easy).
That's essientialy what we do. We took the vcvars32.bat part out but uses
the rest in iclvars.bat
> This would allow bjam to control the back end actively (in case you
> specified 'compatibility').
Have we checked that <compatiblity> option really works this way? My
impression is it only changes the toolset name. I do not know much about
BBv2 so I cannot say for sure.
> Downside: this could clash with environment settings for INCLUDE and LIB
> that have been set before. However, these clashes can never be avoided
> totally anyway. Thinking loudly: is it desirable that bjam *resets*
> these environment settings (INCLUDE/LIB) before setting its own?
I could have misunderstood you. Our experience shows this is ok as long as
the new pathes are added in the front of these environment variables which
is what the batch files do. We do not reset the environments because there
are other things might be needed.
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