Author Topic: Migrating C++ Projects into C::B from Makefiles  (Read 605 times)

Offline Frank_CB

  • Multiple posting newcomer
  • *
  • Posts: 58
Migrating C++ Projects into C::B from Makefiles
« on: November 22, 2019, 06:20:05 pm »
Hello,

Could/would someone please provide some instructions; or point me to some documentation that covers migrating projects into C::B. Code::Blocks' Wiki doesn't cover that subject adequately other to say it can be done.

Regards

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12129
    • Travis build status
Re: Migrating C++ Projects into C::B from Makefiles
« Reply #1 on: November 22, 2019, 09:01:23 pm »
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
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Frank_CB

  • Multiple posting newcomer
  • *
  • Posts: 58
Re: Migrating C++ Projects into C::B from Makefiles
« Reply #2 on: November 28, 2019, 12:26:11 am »
@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   

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6678
    • My Best Post
Re: Migrating C++ Projects into C::B from Makefiles
« Reply #3 on: November 29, 2019, 07:18:06 am »
@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.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Frank_CB

  • Multiple posting newcomer
  • *
  • Posts: 58
Re: Migrating C++ Projects into C::B from Makefiles
« Reply #4 on: December 02, 2019, 05:56:38 pm »
@Stahta01


Code::Blocks can build using a makefile. Lookup custom makefile project in the wiki.

Tim S.


Are you referring to the article by Gavrillo, dated 21 May 2010, entitled 'Code::Blocks and Makefiles'?  If you are, I've tried following it without any success. If that's not the article, I found nothing else on the wiki after doing a literally searching for 'custom makefile project'..

After opening a new empty project, then specifying a custom makefile, then opening the build options 'make commands' tab, I needed to select the release build in the left pane before I could select any command. All commands are grayed-out for the debug build. What to do then? How to invoke a make command from inside c::b? Does the command need to resemble one used from a command prompt? Any suggestions would be appreciated?!

Have you successfully imported a custom makefile into c::b?

Regards

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6678
    • My Best Post
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Frank_CB

  • Multiple posting newcomer
  • *
  • Posts: 58
Re: Migrating C++ Projects into C::B from Makefiles
« Reply #6 on: December 12, 2019, 08:38:52 pm »
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: [Select]
-------------- 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))

Explanation of the error above from the IDE!
Code: [Select]
/*  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>
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


Offline stahta01

  • Lives here!
  • ****
  • Posts: 6678
    • My Best Post
Re: Migrating C++ Projects into C::B from Makefiles
« Reply #7 on: December 13, 2019, 07:33:16 am »
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.
« Last Edit: December 13, 2019, 07:37:18 am by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline sodev

  • Regular
  • ***
  • Posts: 334
Re: Migrating C++ Projects into C::B from Makefiles
« Reply #8 on: December 13, 2019, 08:04:48 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.
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.
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: [Select]
-------------- 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 ;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?
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?