1. Get a build log from the old build system
2. Add the files to a codeblocks project
3. Do a full rebuild
4. Compare the build log to the old build log
5. Make changes
6. Go to 3
@oBFusCATed: Thanks for taking the time to post a reply!1. Get a build log from the old build system
2. Add the files to a codeblocks project
3. Do a full rebuild
4. Compare the build log to the old build log
5. Make changes
6. Go to 3
I need to apologize for not having been more explicit in wording my question. It should have been: "Can a project be migrated through using a makefile?". I had obviously misinterpreted the code::blocks wiki article "Codeblocks and Makefiles". I have since come across an article that pointed out that since there are so many variations of makefiles, that it would impossible for any IDE to be able to import them.
Regards
Code::Blocks can build using a makefile. Lookup custom makefile project in the wiki.
Tim S.
-------------- 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))
/* NULL declaration: it must be defined as 0 for C++ programs (in particular, */
/* it must not be defined as "(void *)0" which is standard for C but completely */
/* breaks C++ code) */
#include <stddef.h>
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.
With a little reformatting the issue is easier to spot. All your includes are relative.Code-------------- 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))
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.
I did re-configure my version of c::b, but that didn't improve anything.If re-configure means that you did something like described in http://wiki.codeblocks.org/index.php/64Bit_Windows (http://wiki.codeblocks.org/index.php/64Bit_Windows) then of course it didn't do anything because you are using an external Makefile. When using an external Makefile the compiler configuration of CodeBlocks DOES NOTHING (@oBFusCATed you are free to slap me with the nasty details i got wrong :) ).
Invoking c::b from within a native developmental command prompt from the directory where the makefile resided allowed both compilers (vc and gcc) to finish successfully.So this answers my question if CodeBlocks does inherit the environment to the compiler process: it does. With the properly setup environment the Makefile does of course work. However i still don't know what you did to produce that output i quoted earlier, probably you modified the Makefile to inject the required paths to work without a properly setup environment?
That rises the question what you actually try to achive?