User forums > Help

Codeblocks and Visual studio 2017 and updates

<< < (2/2)

New Pagodi:
I created the 2 tickets.  Does this seem like a good solution to the constantly changing folders for the include, lib, and executable files; or is there a better way to handle this?

pabristow:
Sorry for delay in replying - I have been away.

Tue 15-Aug-17 18:33 Stephan T. Lavavej <stl@exchange.microsoft.com> wrote on boost@lists.boost.org

The complexity of our versioning story is admittedly a freight train colliding with a dumpster fire orbiting a supernova. Here's the simple form:

* There are two IDEs, VS 2015 (which was updated several times) and VS 2017 (also updated several times so far).

* Each IDE shipped with a corresponding toolset. VS 2015 shipped with toolset v140 (compiler 19.00) and VS 2017 RTM shipped with toolset v141 (compiler 19.10).

* The VS 2017 IDE which ordinarily uses the v141 toolset has the ability to install and use the v140 toolset, without the VS 2015 IDE itself being installed.

* From now on, I will mostly ignore the IDEs and focus on the toolsets (and I will try to be careful to use toolset/compiler versioning - through metonymy I usually refer to toolset versions by their corresponding IDE versions but that isn't a good idea here).

* The v140 toolset (compiler 19.00) uses the Universal CRT in Windows (ucrtbase.dll) and additional DLLs that are part of the VCRedist: vcruntime140.dll, msvcp140.dll, etc.

* We updated the v140 toolset a few times, fixing bugs and (notably) adding features. (These shipped alongside the VS 2015.1, 2015.2, and 2015.3 IDEs.) All updates were binary-compatible and updated the DLLs in-place. This was true even for major updates like fixing the dreaded iostreams floating-point performance regression.

* The v141 toolset (compiler 19.10, originally) still uses ucrtbase.dll, vcruntime140.dll, msvcp140.dll, etc. It is binary-compatible with the v140 toolset, and objects/libs/DLLs can be intermixed freely. That said, it is still a good idea to compile everything consistently with the latest toolset so you receive all correctness/performance fixes, but mixing versions won't trigger crashes or other misbehavior.

* We just updated the v141 toolset, which can be identified by its compiler version (the VS 2017 15.3 IDE update installs a new v141 toolset with compiler 19.11). Again, we've added new features while preserving bincompat.

We're going to a LOT of trouble to preserve binary compatibility, so we hope it is useful. (We are having to be careful when updating the STL - any header change essentially triggers an ODR violation when object files are mixed-and-matched but there are innocuous ODR violations and poisonous ODR violations, and we know how to tell the difference.)

which is more than you (or I) want to know.

Any solution should use some VSvarsall.bat which sets all the INCLUDEs and LIBRARY etc.

The various versions are now at

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Auxiliary\Build

So vcvars64.bat does

@call "%~dp0vcvarsall.bat" x64 %*

setting things up for 64 bit aka x64 and similarly vcvars32.bat  for 32-bit aka x86.

I don't understand how this magic works, but it seems fundamental?

(For example the Boost preferred build system b2/bjam creates the appropriate version of vsvarsall.bat to call from the build jamfile call, for example

   b2 toolset=clang-6.0.0 address-model=64 architecture=x86

  C:\LLVM\clang-600\LLVM\lib\clang\6.0.0\include
  C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\include
  C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt
  C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\shared
  C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\um
  C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\winrt   <<<< new addition.

I'm not sure of this helps much, but it is what I think I know ;-)

It would be nice to be able to use the free Visual Studio community edition for anyone who wants to be able to confirm that code runs the same on VS, GCC and Clang using the same IDE.  (Of course the VS IDE is still better than Codeblocks, but doesn't run GCC, or Clang (fully for me) yet).

BlueHazzard:
interesting story... Microsoft and the binary compatibility is famous...

next time use the quote tag if you quote someone, so it gets a lot easier to read...

Navigation

[0] Message Index

[*] Previous page