cbp2make - makefile generation tool

[mirai]

Update: (see rev.133)

• Fixed reading of virtual targets from project file. All virtual targets but the first one were missing due to a bug.
  
• Implemented build target selection for virtual targets. Previously, target selection with option "-targets" worked only for real build targets, but now it works for virtual targets as well.
  

[Lefteris]

Hello!

This tool is exactly what I was searching for. I am in Windows and I am trying to create a makefile from my .cbp project. The problem is that when I try to do that cbp2make crushes immediately.

I am typing in:

Code Select Expand

cbp2make -in foo.cbp
The output I get is:

Code Select Expand

Starting cbp2make rev.133...
Using default configuration.
Loading file 'foo.cbp': [DONE]
Generating makefile(s): foo.cbp.mak:


After that the crush happens.

Any idea why this might be happening or methods to correct it?
My project is actually cross-platform thanks to CB so, I am gonna go to my Linux pc and try to run cbp2make in the same project from there and see the results.

I tested it in Linux too and the same thing happened. So it must be something inside the .cbp file
I have different build targets in the .cbp project. Should not affect the generation process though right?


Further Edit:
Since I had the source I thought I should try to debug it and maybe see if the seg fault is something easy to fix. After lots of trial and error and updates on this post I found what was happening.

The problem is in line 1098 of src\cbproject.cpp

Code Select Expand


    CBuildUnit *unit = m_UnitIndex[i];
    CCompiler *compiler = tc->FindCompiler(unit->Extension());
    /*
    std::cout<<"target "<<target->Name().GetString()
             <<" unit "<<unit->m_FileName.GetString()
             <<" compilable "<<unit->IsCompilable()
             <<" compile "<<unit->m_DoCompile
             <<" link "<<unit->m_DoLink<<std::endl;
    */
    if( compiler !=0) /// Extra check added by Lefteris, so as not to delete the original check
    {
   //if (((0!=compiler)||(!unit->CompilerVariable().IsEmpty()))&&(unit->DoCompile()))//original check
     CString compiler_var = compiler->MakeVariable(); /// SEG FAULT HERE
     if (unit->CompilerVariable().IsEmpty())
     {
      compiler_var = compiler->MakeVariable();
     }


The original if check allows  the program to get in the compilable unit scope even if the CCompiler* pointers is 0. So for all the header files of my project it was getting in there and was causing a seg fault.

I made a temporary fix of this if check by just checking only for compiler pointer being 0.

Further Edit 2

I discovered another bug. In windows during the linking stage the loading flags were output to the
beginning right after the $(LD). That resulted in undefined referenced during making.

Code Select Expand


out_win32_debug_test: $(OBJ_WIN32_DEBUG_TEST) $(DEP_WIN32_DEBUG_TEST)
$(LD)  $(LDFLAGS_WIN32_DEBUG_TEST) $(LIBDIR_WIN32_DEBUG_TEST) $(OBJ_WIN32_DEBUG_TEST) $(LIB_WIN32_DEBUG_TEST) -o $(OUT_WIN32_DEBUG_TEST)

I am not sure if this is an issue of cbp2make or if it is supposed to be okay to put the Loader Flags wherever you want, but moving them to the very end like that solved my problem.

Code Select Expand


out_win32_debug_test: $(OBJ_WIN32_DEBUG_TEST) $(DEP_WIN32_DEBUG_TEST)
$(LD) $(LIBDIR_WIN32_DEBUG_TEST) $(OBJ_WIN32_DEBUG_TEST) $(LIB_WIN32_DEBUG_TEST) -o $(OUT_WIN32_DEBUG_TEST) $(LDFLAGS_WIN32_DEBUG_TEST)


[mirai]

Thanks for testing the tool. I will recheck this issue and apply a permanent fix. You can help me by sending a sample project file that caused crash in rev.133 to my email.

Considering options order, you can rewrite command line for Windows platform in cbp2make configuration. Just run "cbp2make --config options --local" in project directory and then change defaults in cbp2make.cfg to your corrected version by moving around macros in linkage command. I'm not sure if I have to change defaults, C::B uses just the same order of linker options.

Update: your issue is now registered here: https://sourceforge.net/apps/mantisbt/cbp2make/view_all_bug_page.php

[Freem]

If you are the maintainer of the sourceforge's website of cbp2make, you have a problem with your website, you redirect on a php page... and here (opera browser) I can only save it.

[mirai]

If you are the maintainer of the sourceforge's website of cbp2make, you have a problem with your website, you redirect on a php page... and here (opera browser) I can only save it.

That site is simply a wiki provided by sourceforge, I didn't do anything weird to it and didn't even touched it for a long time. Maybe something is got broken on sf.net side... Now have to contact sf.net administration  .

[stahta01]

If you are the maintainer of the sourceforge's website of cbp2make, you have a problem with your website, you redirect on a php page... and here (opera browser) I can only save it.

That site is simply a wiki provided by sourceforge, I didn't do anything weird to it and didn't even touched it for a long time. Maybe something is got broken on sf.net side... Now have to contact sf.net administration  .

The Wiki for another site on sourceforge stopped working today.

Note: This site that says what is down is also down
https://sourceforge.net/apps/wordpress/sourceforge/

Edit: I get this message today.

With the exception of Trac, the Hosted Apps platform on the SourceForge site are offline.

-- SourceForge.net team.
Site Status:

loading latest tweet...

Tim S.

[mirai]

Update: (see rev.135)

• Fixed possible crash when compiler variable is overridden for a unit and that unit has an unrecognized extension.
  
• Quick fix for handling relative paths outside project tree. Elements ".." of relative paths for object files are replaced with "__" strings, so all object files which sources are outside of project tree will be along all other object files in a specified subdirectory of the project.
  

[mirai]

Update: (see rev.137)

• For Windows GUI builds "-mwindows" option is now supplied to the GCC linker, for other manually added compilers (toolchains), an "option_wingui" is available in the cbp2make configuration.
  
• Fixed output path for Windows resource compiler (a path separator was missing).
  
• Removed false messages about missing compiler for non-compilable units.
  
• Fixed command line syntax for linking with libraries, some project options were mistreated and "-l" switch was misplaced.
  

[axus]

I made an account to say thank you!  I like to use MinGW32 + msys, and I'm trying to build SFML without codeblocks.  It looks like it will work once I install Qt.

One request, if HOME env is defined, I'd rather use it than Windows user path.  It seems that --config didn't create the .cbp2make directory in C:/Users/Account automatically from MSYS.  --local works OK.  All the different toolchain settings are overwhelming, but I didn't need them so no problem.

[mirai]

One request, if HOME env is defined, I'd rather use it than Windows user path.  It seems that --config didn't create the .cbp2make directory in C:/Users/Account automatically from MSYS.  --local works OK.  All the different toolchain settings are overwhelming, but I didn't need them so no problem.

I just followed the Qt implementation in this regard, but overriding this default behavior is not a problem I think.
Good piece of plan for the next release.

[Kenneth McGregor]

I generated a makefile using this tool and it looks great, thanks! However when I "make"  the project, it does not find the wxWidgets libraries even though the `wx-config --libs` directive is there. It does find the wxWidgets include files using the `wx-config --cflags` directive. If I just cut and paste the output from wx-config --libs command run manually into the generated makefile at the line LIB =, everything works fine. It's like the `wx-config --libs` command does not get run at the linker step, even though it's there. The use of wx-config is a must for wxWidgets if one is planning on distributing an open source program.

Any suggestions?

Thanks,
Ken

[oBFusCATed]

The use of wx-config is a must for wxWidgets if one is planning on distributing an open source program.

I'd rather say that learning autotools is a must when one wants to distribute open source programs.

On the problem: have you tried to for make to print debug output and see what commands get executed?

[Kenneth McGregor]

I agree with your autotools comment. However, one really needs a makefile to use as a makefile.in template. And yes, I have used the -n option. The line in question is:

g++ -s `wx-config --libs` -L/usr/local/lib obj/Release/src/PicKit2Main.o obj/Release/src/PicKit2App.o obj/Release/src/HexTextCtrl.o obj/Release/src/HexRecord.o obj/Release/src/HexEditDlg.o obj/Release/src/HexEditCtrl.o obj/Release/src/DeviceFile.o obj/Release/src/DeviceDlg.o  -o bin/Release/pk2cmdUI

[Kenneth McGregor]

The wxWidgets team solved this.

If you move the `wx-config --libs` to the end, just before the -o, it works.

The author of cbp2make should make note of this.

Thanks,
Ken

[mirai]

AFAIK, a wxWidgets project is configured using a global compiler variable WX in terms of Code::Blocks IDE.
Dereferencing this variable with #WX is purely mechanical, and placing the macro in a command line is up to the author of a project.
cbp2make does not enforce the placement of the macro in any exact location, the tool just makes string substitutions.

Please correct me if I'm wrong at this point.