Then I modified makefile.vc, since c::b, while using the currrent vc compiler doesn't use environment variables, like c::b does while using the gnu compiler, and then successfully rebuilt it again.
I don't understand that. C::B can't change how any compiler works. MSVC relies on the presence of certain environment variables to find e.g. includes and libs like INCLUDE and LIB unless you specify them explicit on the command line, so does C::B remove these if it executes a compiler? I doubt that, it's more likely that you didn't run C::B inside a so called development shell but a plain shell and these varibales simply haven't been setup. Most probably your GCC is installed "system wide" and pollutes your global environment with its variables so every shell contains them so GCC works "everywhere".
I then migrated each of the makefiles into the IDE.
What did you "migrate"? Doesn't C::B just execute them as external makefiles? There is nothing to change or migrate in these files.
-------------- Build: Debug x64 in dataview (compiler: mvc x64)---------------
Checking if target is up-to-date: nmake.exe -q -f c:\wxwidg~1.3\samples\dataviewcbvcmake2\makefile.vc TARGET_CPU=X64 all
Running command: nmake.exe -f c:\wxwidg~1.3\samples\dataviewcbvcmake2\makefile.vc TARGET_CPU=X64 all
Microsoft (R) Program Maintenance Utility Version 14.23.28107.0
Copyright (C) Microsoft Corporation. All rights reserved.
cl /c /nologo /TP /Fovc_mswud_x64\dataview_dataview.obj /MDd /DWIN32 /Zi /Fdvc_mswud_x64\dataview.pdb /D_DEBUG /Od /D_CRT_SECURE_NO_DEPRECATE=1 /D_CRT_NON_CONFORMING_SWPRINTFS=1 /D_SCL_SECURE_NO_WARNINGS=1 /D__WXMSW__ /D_UNICODE
/I.\..\..\lib\vc_x64_lib\mswud
/I.\..\..\include
/I.
/I.\..\..\samples
/I.\..\..\2019\Community\VC\Tools\MSVC\14.23.28105\atlmfc\include
/I.\..\..\2019\Community\VC\Tools\MSVC\14.23.28105\include
/I.\..\..\10\Include\10.0.18362.0\cppwinrt
/I.\..\..\10\Include\10.0.18362.0\shared
/I.\..\..\10\Include\10.0.18362.0\ucrt
/I.\..\..\10\Include\10.0.18362.0\um
/I.\..\..\10\Include\10.0.18362.0\winrt
/W4 /GR /EHsc /MP /D_WINDOWS /DNOPCH /GR /EHsc .\dataview.cpp
dataview.cpp
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.23.28105\bin\Hostx64\x64\cl.EXE"' : return code '0x2'
Stop.
C:\wxWidgets-3.1.3\include\wx/defs.h(707): fatal error C1083: Cannot open include file: 'stddef.h': No such file or directory
Process terminated with status 2 (0 minute(s), 0 second(s))
1 error(s), 0 warning(s) (0 minute(s), 0 second(s))
With a little reformatting the issue is easier to spot. All your includes are relative.
I don't know what working directory C::B sets on executing an external makefile, i would guess the directory of the makefile, but this doesn't matter with these include definitions. For these to work you need to be in three different working directories at the same time
(unless you moved around your MSVC und SDK installations). Assuming default installation paths, for the MSVC includes to work you need to be inside
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community, for the SDK includes inside
C:\Program Files (x86)\Windows Kits\10\Include and for the wxWidgets includes you are probably inside
build\msw of its source tree. Too bad there can be only one working directory at a time
.
Any idea why the IDE hiccuped? sodev mentioned over a year ago that the developers of codeblocks had stopped supporting visual c++ since 2015. Any significance?
I was referring to the fact that there are no compiler definitions available for the more recent versions so you have to create them yourself. This is kind of some work because especially the recent versions require a lot of paths to setup. Plus without a predefined name you cannot share such project files with someone else because he needs to use the same name for his compiler definitions like you because these are stored inside the project files.
But this is no problem for your use case because you use external makefiles and these don't use the C::B build system and hence need no compiler definitions
. That rises the question what you actually try to achive?