Linux CodeBlocks & wxWidgets 2.6

[grv575]

Just thought I'd put up a separate topic to corfirm that codeblocks works with wxWidgets 2.6.1 under Linux now.
Thanks to byo for figuring out the compile setting that were giving crashes.
 
The CVS version of the makefile (and .cbp file) still need to incorporate changes to get this running which I've listed below.
These are the minimal changes, as most of the CFLAGS) already there are desired (e.g. -f-message-length):

Code

1.  remove -fno-pcc-struct-return :
*_GLOBAL_CFLAGS= 
*_PROJECT_CFLAGS= -Wall -g -pipe -fmessage-length=0 `wx-config --cflags`

2.  add #defines for scintilla :
scintilla_CFLAGS= $(scintilla_PROJECT_CFLAGS) -DGTK -DSCI_LEXER -DLINK_LEXERS -DWXMAKINGDLL_SCI $(scintilla_GLOBAL_CFLAGS)

3.  add -Ldevel for sdk :
sdk_PROJECT_LIBDIRS= -Lsdk/tinyxml -Ldevel

4.  add compilerSDCC sources (Should just be added to the .cbp obviously and then exported):
---
plugin_CompilerGCC_OBJS=...    .deps/plugins/compilergcc/compilerSDCC.d   ....

dist:
	@zip ...   plugins/compilergcc/compilerSDCC.cpp plugins/compilergcc/compilerSDCC.h   ...

.deps/plugins/compilergcc/compilerSDCC.d: plugins/compilergcc/compilerSDCC.cpp
	$(plugin_CompilerGCC_CPP) -MM $(plugin_CompilerGCC_CFLAGS) -MF .deps/plugins/compilergcc/compilerSDCC.d -MT .objs/2.6/plugins/compilergcc/compilerSDCC.o $(plugin_CompilerGCC_INCS) plugins/compilergcc/compilerSDCC.cpp
	
.objs/2.6/plugins/compilergcc/compilerSDCC.o: .deps/plugins/compilergcc/compilerSDCC.d
	$(plugin_CompilerGCC_CPP) $(plugin_CompilerGCC_CFLAGS) $(plugin_CompilerGCC_INCS) -c plugins/compilergcc/compilerSDCC.cpp -o .objs/2.6/plugins/compilergcc/compilerSDCC.o	
---
5. remove --no-check-associations
from CodeBlocks-unix-wx2.6.0.cbp

So these are the minimal changes needed to the current Linux makefile to get it to compile and run cleanly.
(the GLOBAL_CFLAGS -Dxxx defines from the makefile byo posted shouldn't be hardcoded - they are generated by the `wx-config --cflags` command.
The only PROJECT_CFLAGS which needed to be removed was the no pascal calling convention for struct returns flag: -fno-pcc-struct-return)

Note that there are no crashes, all the dialogs seem to be there and function ok, but there are still bugs that need to be worked out  (for example creating a new project doesn't add the .cbp extension so it fails to import it, and creating a new project doesn't generate the .cpp source... but I'm sure there these will be fixed soon enough now that the linux version no longer crashes).

Attached is the modified makefile (CVS makefile with changes listed above).


[attachment deleted by admin]

[fiammy]

 
Great! I'll check this makefile out ASAP (I'm at work now, but tonight I'll have a new go at the compilation under Linux).

Thanks!

[grv575]

I compiled the windows version without the -fno-pcc-struct-return CFLAGS flag.  Tested and it works perfectly.  I propose we just get rid of the flag unless there is some specific reason for having it.  The resulting binary seems to run slightly faster (my imagination?) - maybe better optimized but the main thing is that it should be more stable to use the same set of flags on both platforms when diagnosing bug reports.

[grv575]

OK fixed the no .cbp on new project bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=1280345&group_id=126998&atid=707416

sdk/templatemanager.cpp:197
-                         pt->m_Name,
+                        pt->m_Name + _T(".cbp"),

[mandrav]

OK fixed the no .cbp on new project bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=1280345&group_id=126998&atid=707416

sdk/templatemanager.cpp:197
-                         pt->m_Name,
+                        pt->m_Name + _T(".cbp"),

This fix, doesn't fix the problem correctly.
1) You just changed the dialog's suggestion. If the user types another filename and doesn't add the extension manually, it will still fail.
2) What if the user creates a new empty project (not from template)?

In CVS this bug has been fixed and works correctly in all cases...

[grv575]

Great thanks! 

[grv575]

Actually, just tested this.  It generates the project name correctly, but isn't naming the main.cpp file correctly or adding it to the console.cbp file:

Code

<?xml version="1.0"?>
<!DOCTYPE Code::Blocks_project_file>
<Code::Blocks_project_file>
	<FileVersion major="1" minor="1"/>
	<Project>
		<Option title="Console application"/>
		<Option makefile="Makefile"/>
		<Build>
			<Target title="default">
				<Option type="1"/>
				<Option parameters=""/>
				<Option includeInTargetAll="1"/>
				<Option projectCompilerOptionsRelation="3"/>
				<Option projectLinkerOptionsRelation="3"/>
				<Option projectIncludeDirsRelation="3"/>
				<Option projectLibDirsRelation="3"/>
				<Compiler>
					<Add option=""/>
				</Compiler>
				<Linker>
					<Add option=""/>
				</Linker>
			</Target>
		</Build>
	</Project>
</Code::Blocks_project_file>

vs:

Code

<?xml version="1.0"?>
<!DOCTYPE Code::Blocks_project_file>
<Code::Blocks_project_file>
	<FileVersion major="1" minor="1"/>
	<Project>
		<Option title="Console application"/>
		<Option makefile="Makefile"/>
		<Option makefile_is_custom="0"/>
		<Option compiler="0"/>
		<Build>
			<Target title="default">
				<Option output="/root/test3/console"/>
				<Option working_dir="."/>
				<Option object_output=".objs"/>
				<Option deps_output=".deps"/>
				<Option external_deps=""/>
				<Option type="1"/>
				<Option compiler="0"/>
				<Option projectResourceIncludeDirsRelation="1"/>
			</Target>
		</Build>
		<Unit filename="main.cpp">
			<Option compilerVar="CPP"/>
			<Option target="default"/>
		</Unit>
	</Project>
</Code::Blocks_project_file>

[attachment deleted by admin]

[rickg22]

Cool! So, is the makefile fixed now?

[mandrav]

I compiled the windows version without the -fno-pcc-struct-return CFLAGS flag.  Tested and it works perfectly.  I propose we just get rid of the flag unless there is some specific reason for having it.  The resulting binary seems to run slightly faster (my imagination?) - maybe better optimized but the main thing is that it should be more stable to use the same set of flags on both platforms when diagnosing bug reports.

Yes, we can get rid of -fno-pcc-struct-return.
As for feeling faster, I bet the new thread pool did its magic

[grv575]

More on the bug above:

The .cbp file is not the issue.   Both windows and Linux versions generate the same. cbp file and then save it with the <Units> tags once the project is closed.   So actually closing the project and then reopening it on Linux works ok.   You only get the blank filename for the Cpp source file when you first create the project (Linux version).  The message:
"End parsing project Console application (no files found?)"
appears on both Windows and Linux but only the windows version picks up the main.cpp filename :?

[grv575]

OK, forget that bug report.  It's either fixed in the latest CVS or it was a matter of updating some of the template in the unix.wx2.6 .cbp file and then creating a new makefile.

So using a diff program, I've synched the windows .cbp changes to unix.wx2.6 one.  Then created a new unix makefile which works.  From what I've tested everything works great.  Really responsive too.  Overall very usable so finally a good ide for linux (not a kdevelop or eclipse fan).

Attached are the updated unix-wx2.6 .cbp and Makefile.  Please check for correctness of course but I think it should be fairly close anyhow.


[attachment deleted by admin]

[mandrav]

OK, forget that bug report.  It's either fixed in the latest CVS or it was a matter of updating some of the template in the unix.wx2.6 .cbp file and then creating a new makefile.

It was a bug for a couple of hours until I noticed and fixed it.
But since you 're on anoymous cvs, you get the updates with 4-6 hours delay.

That's why this kind of bug report should be discussed in the developers' area. It's only temporary and regular users shouldn't be scared-off...