User forums > General (but related to Code::Blocks)
Migrating C++ Projects into C::B from Makefiles
stahta01:
http://wiki.codeblocks.org/index.php/Code::Blocks_and_Makefiles
http://wiki.codeblocks.org/index.php/FAQ-Compiling_(general)#Q:_My_project_should_be_compiled_with_a_custom_makefile._Is_it_possible_with_Code::Blocks.3F
Tim S.
Frank_CB:
Hello,
I've worked out migrating project(s) into Codeblocks' IDE. @oBFusCATed and @stahta01, thanks again for your responses. They finally ignited a light-bulb. The web contains vast quantities of information about 'Make'.
While completely outside of the Codelocks IDE, I have built the wxWidgets dataview sample with both make and nmake using the supplied default makefiles. 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 then migrated each of the makefiles into the IDE. I successfully built the sample using mingw_W64 8.0. Using Visual C++ 16.0, I get the following error(s) using the same sample.
The error(s):
--- 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))
--- End code ---
Explanation of the error above from the IDE!
--- Code: ---/* 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>
--- End code ---
stddef.h is not in any library on my system.
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?
Regards
stahta01:
Do you understand that a makefile problem is not an Code::Blocks problem?
Edit: Code::Blocks just calls the make command and then the build is controlled by the makefile!
Tim S.
sodev:
--- Quote from: Frank_CB on December 12, 2019, 08:38:52 pm ---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.
--- End quote ---
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".
--- Quote ---I then migrated each of the makefiles into the IDE.
--- End quote ---
What did you "migrate"? Doesn't C::B just execute them as external makefiles? There is nothing to change or migrate in these files.
--- Quote ---
--- 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))
--- End code ---
--- End quote ---
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 ;D (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 :P.
--- Quote ---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?
--- End quote ---
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?
Frank_CB:
@sodev and @stahta01: Thanks!!
I am going to re-configure my version of c::b following Tjaalie's wiki article and hopefully adapt it for Windows 10.
The current configuration of c::b still can't seem to find stddef.h, even after replacing it on my system. I had previously used makefiles successfully within and outside of IDEs, but not c::b. Hopefully this change will improve things.
@sodev: With regard to developers no longer supporting vc compilers; not being updated since 2015 is what I meant. I'll take the rest of your reply under advisement .
Regards,
Frank
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version