Codeblocks and Visual studio 2017 and updates

[pabristow]

Has anyone got Visual Studio 2017 Pro (or Community) to work with Codeblocks?

The Visual Studio (and tools and kits) directory structure has completely and radically changed for this version (and will keep changing rapidly with the very frequent MS update - Hurrah!)

The toolchain cl.exe etc are at

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\bin\Hostx64\x64

and not in the folder /bin  and things start OK

So I have put this at the 'root' toolchain folder and that seems to get started.

-------------- Build: vs2017_Release in hello_boost (compiler: Visual Studio 2017)---------------

cl.exe -Wall -fexceptions -O2 -DBOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE -Wall -II:\modular-boost -II:\modular-boost -I"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\include" -I"C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt" -c J:\Cpp\Misc\hello_boost\hello_boost.cpp -o obj\Release\Misc\hello_boost\hello_boost.o
link.exe -L"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\lib" -o bin\Release\hello_boost.exe obj\Release\Misc\hello_boost\hello_boost.o  -s  "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\lib"
Microsoft (R) C/C++ Optimizing Compiler Version 19.13.26129 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.
cl : Command line warning D9035 : option 'o' has been deprecated and will be removed in a future release
cl : Command line warning D9002 : ignoring unknown option '-fexceptions'
hello_boost.cpp

but then produces zillions of errors


C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\malloc.h(44): warning C4820: '_heapinfo': '4' bytes padding added after data member '_heapinfo::_useflag'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\include\vcruntime_exception.h(25): warning C4820: '__std_exception_data': '7' bytes padding added after data member '__std_exception_data::_DoFree'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\include\vcruntime_typeinfo.h(44): warning C4820: '__std_type_info_data': '7' bytes padding added after data member '__std_type_info_data::_DecoratedName'
I:\modular-boost\boost/config/stdlib/dinkumware.hpp(99): warning C4668: '_HAS_NAMESPACE' is not defined as a preprocessor macro, replacing with '0' for '#if/#elif'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\include\xlocinfo.h(59): warning C4820: '_Collvec': '4' bytes padding added after data member '_Collvec::_Page'
...
J:\Cpp\Misc\hello_boost\hello_boost.cpp : warning C4710: 'class std::basic_ostream<char,struct std::char_traits<char> > & __ptr64 __cdecl std::endl<char,struct std::char_traits<char> >(class std::basic_ostream<char,struct std::char_traits<char> > & __ptr64)': function not inlined


and finally the link fails thus

Microsoft (R) Incremental Linker Version 14.13.26129.0
Copyright (C) Microsoft Corporation.  All rights reserved.
LINK : warning LNK4044: unrecognized option '/LC:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\lib'; ignored
LINK : warning LNK4044: unrecognized option '/o'; ignored
LINK : warning LNK4044: unrecognized option '/s'; ignored
LINK : fatal error LNK1181: cannot open input file 'bin\Release\hello_boost.exe'

Should the setup file vsvarsall.bat be involved in the startup process?

Has anyone got this working properly (preferably with Boost and most important for me Boost.Test)?

Thanks for any hints and clues.

[sodev]

Well, this happens when you use the GCC compiler settings with MSVC . Use the Visual Studio 2010 compiler settings and adapt accordingly . Just a few days ago i posted the links to my 2015 setup here, you can take this as a guidance.

[New Pagodi]

I've been trying to find a good solution for this too.  What I've tried so far is to define 4 custom variables:
WINSDKROOT="C:\Program Files (x86)\Windows Kits\10"
WINSDKVERSION=10.0.16299.0 (or whatever kit is being used)
VCROOT=(whatever path visual c++ was installed to)
VCVERSION=14.13.26128 (or whatever the current version is)

Then I set the compiler and resource compiler search path to:
$(VCRoot)\$(VCVersion)\include
$(WinSDKRoot)\include\$(WinSDKVersion)\shared
$(WinSDKRoot)\include\$(WinSDKVersion)\ucrt
$(WinSDKRoot)\include\$(WinSDKVersion)\um

and the linker search path to:
$(VCRoot)\$(VCVersion)\lib\x64
$(WinSDKRoot)\lib\$(WinSDKVersion)\ucrt\x64
$(WinSDKRoot)\lib\$(WinSDKVersion)\um\x64

This way whenever the visual c++ kit gets updated, I only have to change the VCVERSION variable.  Likewise, when a new SDK is released, I only have to change the WINSDKVERSION variable.

The problem is that this doesn't work for the toolchain executable paths if they have spaces in them.  For example if I try to set the compilers installation directory to

Code

$(VCRoot)\$(VCVersion)\bin\Hostx64\x64

where VCRoot is something like "C:\Program Files\Microsoft Visual Studio 2017\VC\Tools\MSVC", the path for the compiler will get expanded to

Code

"C:\Program Files\Microsoft Visual Studio 2017\VC\Tools\MSVC"\14.13.26128\bin\Hostx64\x64\cl.exe

Apparently windows doesn't like having part of the full path quoted and the rest unquoted, so when codeblocks tries to invoke the compiler with that command, it fails.  So the only thing I think I can do is reset the compilers's installation directory setting in addition to changing the VCVERSION variable everytime visual c is upgraded.

Does anybody have a better solution?

[New Pagodi]

After trying a few more things, I've noticed that adding the following Aditional paths on the Toolchain executables page works:

C:\Program Files\Microsoft Visual Studio 2017\VC\Tools\MSVC\$(VCVersion)\bin\Hostx64\x64
C:\Program Files (x86)\Windows Kits\10\bin\$(WinSDKVersion)\x64
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

Codeblocks is able to find and invoke the compiler, resource compiler, and linker.  And I think that way just changing VCVersion when visual c is updated and changing WinSDKVersion when the SDK is updated would be enough to keep both the includes/libs and the executables working.  I'd rather keep those paths bottled up in the compiler variables like I can with the include/lib paths, but I guess it's better than nothing.

However there's still one problem.  When codeblocks launches, it pops up a warning that it can't find the compiler in the executable search path.  I assume this is either because the executables are not in a "bin" folder.  They're in a folder named something like "...\bin\Hostx64\x64" or "...\bin\Hostx86\x64".  Or it could be the variables in the paths aren't expanded in the check done when codeblocks starts. 

Is there a way to stop this pop up warning when codeblocks starts?

[BlueHazzard]

Ok, you have hit quite a lot bugs here. Lets sum them up:
1)

Code

$(VCRoot)\$(VCVersion)\bin\Hostx64\x64

gets expanded into

Code

"C:\Program Files\Microsoft Visual Studio 2017\VC\Tools\MSVC"\14.13.26128\bin\Hostx64\x64\cl.exe

I hate windows for using spaces in important paths, but this is clearly a bug

2)

However there's still one problem.  When codeblocks launches, it pops up a warning that it can't find the compiler in the executable search path.  I assume this is either because the executables are not in a "bin" folder.  They're in a folder named something like "...\bin\Hostx64\x64" or "...\bin\Hostx86\x64".  Or it could be the variables in the paths aren't expanded in the check done when codeblocks starts.

can you open two tickets on Source forge so they wont get lost?
i will try to look into them as soon as i find some time... (but there still needs to be a dev to review them and merge them into trunk)

[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...