Configuring Code::Blocks using Visual Studio 2019 compiler (MSVC)

[cacb]

I have recently installed Visual Studio 2019 Enterprise Under Windows 10 and configured it for use in Code::Blocks under the generic name 'MSVC'. My projects all refer to a generic 'MSVC' compiler on Windows. This way the project files are unaffected by a compiler upgrade from MSVC2013 to MSVC2019 (or any other combination of compiler versions). The user defined MSVC compiler relies on definitions in C::B global variables to make things easier and avoid repetition.

There is a quick writeup for MSVC2019 configuration at this address
https://github.com/arnholm/cpde_utils/blob/master/doc/toolchain/CodeBlocks_MSVC2019_setup.pdf

I still have MSVC2013 installed, and I am able to switch between these compilers using the 'cb_config' tool found in https://github.com/arnholm/cpde_utils . It works by editing the C::B XML configuration file default.conf. C::B must obviously be closed when this happens so 'cb_config' refuses to do anything if C::B is running.

Switching between MSVC2013/MSVC2019 compilers means to overwrite the definition of the MSVC user defined compiler with settings from either MSVC2013 or MSVC2019 - also user defined compilers. Typically different sets of global variables goes along with each compiler so the corresponding global variable set should be activated at the same time, so this can also be done in 'cb_config'.

In theory you could do these things from within C::B, but changing active global variable set has always been a bit confusing, it does not seem to be activated 100% unless you close and restart C::B. Redefining 'MSVC' to contain definitions for a specific compiler version is impractical if you need to switch back and forth, doing it using the 'cb_config' tool is much easier for my setup.

It would be nice to have these capabilities integrated into the C::B GUI, but using 'cb_config' seems to work fine for now. If you need only MSVC2019, the writeup above should be sufficient.

[sodev]

The usage of global variables to store toolchain related information is a really nice idea, actually i didn't know that these can be used in these locations. This should help a lot to deal with changing version numbers because of frequent updates, i am going to use that approach to improve my workflow .

I am also using different MSVC versions/variants with CodeBlocks but i use a different approach, i am using "tagged" variables and compilers. I have multiple compiler definitions like msvc140_xp, msvc142_x86 together with global variables for external libraries like boost_vc142_x86, wx31_vc142_x86. However i am not using handwritten Project Files but generate them with a heavily modified Premake 3.x. With this setup i just have to specify the comiler during the generation and don't have to change anything in CodeBlocks when i switch to different projects.

[BlueHazzard]

You can use global variables nearly everywhere... Sadly this also slows down the compiling process quite a bit...

[Alex@SM]

It is better to recompile pdf document to txt )

For MSVC19 Preview
X64
 
cl.exe, link.exe
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.27.28919\bin\Hostx64\x64

rc.exe
C:\Program Files (x86)\Windows Kits\8.0\bin\x64\rc.exe

//==================================================

X32
cl.exe, link.exe
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.27.28919\bin\Hostx64\x86

rc.exe
C:\Program Files (x86)\Windows Kits\8.0\bin\x86\rc.exe

//==================================================
includes (search directories-> compiler)

C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\shared
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt
C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.27.28919\include
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include
C:\Program Files\Microsoft Visual Studio 8\VC\include

search directories-> linker (for x64)

C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\um\x64
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.16.27023\lib\onecore\x64
C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\ucrt\x64
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.16.27023\lib\x64\store

Works fine! Thanks.
PS Pitty that C::B is obsolete for MAC.

[cacb]

I have recently installed on another computer using MSVC2019 "Community Edition" and this work fine too.

[Alex@SM]

It seems that the MSVC Preview version is not free so I am changing it to the Comunity Edition also. I guess it would not require many changes in C::B setup that I posted. Otherwise, I will let everyone know..

[pjones0]

Surely there must be a default.conf and any other files that code::blocks needs to be able to access the VS C++ 20XX (2017) greater compiler/linker??? I tried modifying the .confg file to include a msvcXX entry--like msvc8 and added a options_msvcXX.xml, but I still can't get it to work.  Any help from any CB guru's???

[Miguel Gimenez]

Support for MSVC2017 was added to trunk in January, so any younger nightly should include it.

[cacb]

Surely there must be a default.conf and any other files that code::blocks needs to be able to access the VS C++ 20XX (2017) greater compiler/linker??? I tried modifying the .confg file to include a msvcXX entry--like msvc8 and added a options_msvcXX.xml, but I still can't get it to work.  Any help from any CB guru's???

The default.conf file contains a lot of information irrelevant to getting MSVC compiler configured in C::B.  The details are really explained for MSVC2019 community edition in the PDF of the first post. I still use that setup. I recommend you spend some time studying that.

Start by defining the 5 user defined global variables: msvc, msvc_toolchain, net_sdk, win_sdk and win_sdk_lib. Use the lobal variable editor. Save by exiting C::B at intervals.

Then define the user defined compiler named MSVC and set its search directories etc. referring to the global variables mentioned and documented in the PDF. I have not experienced any significant slowdown in compiling/linking doing it this way. Make it the default compiler.

It takes a bit of effort to configure things this way, but one benefit is that the C::B project files (I have many) become largely independent of the actual MSVC compiler being used, so upgrading is easier.

I also have an extremely simplified setup for creating new preconfigured projects for the user defined MSVC compiler, essentially a few typical projects with token project names. When creating a new project I simply run a search/replace utility and voila I have a new project file that works the way I want it.

I do not integrate MSVC debugging in the C::B ide. For this I use a C::B Tools menu entry to start the MSVC IDE in debug mode with the current C::B editor file+line as the current debugging point. Not super fancy, but it works well enough for my use.