Subject: Re: [Boost-bugs] [Boost C++ Libraries] #9214: (Windows) bjam should choose the msvc version from the current visual studio prompt
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-11-26 15:40:04
#9214: (Windows) bjam should choose the msvc version from the current visual
studio prompt
-------------------------------+----------------------------
Reporter: desurium@⦠| Owner:
Type: Bugs | Status: new
Milestone: To Be Determined | Component: Building Boost
Version: Boost 1.53.0 | Severity: Problem
Resolution: | Keywords:
-------------------------------+----------------------------
Comment (by desurium@â¦):
I do know this command line option. I just don't find it very usefull in
an automatic build environment or on a developer machine, where you want
to build your dependencies as well.
It would be sufficient to have a new command line option like "compiler-
detection={auto,cli,off}". I could try to implement such a command line
option.
But with only "toolset" as the only option, everybody has to check the
current active compiler in such an build environment and pass the already
choosen compiler version (it was explicitly choosen before by selecting a
msvc cli or setting CXX) to bjam again.
But something new came into my mind: How does bjam searches for gcc if
multiple gcc installations are installed? Does it check CXX? Does it
chooses the global activated gcc?
I don't think, that is the "best way". Selecting the newest versions if it
is possible to say, that the user wants a different compiler isn't
intuitive and leads to errors you may notice only very late.
Especially for the STL library it can cause different problems if you mix
binaries compiled with different STLs.
Anyway I don't see any benefit with the current behaviour. What advantages
does it have over checking the current active msvc compiler from the
environment?
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/9214#comment:2> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:14 UTC