Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Splitting debugger in two - specific debugger and common GUI
oBFusCATed:
I was planning to submit the patches to upstream, but I've not done so.
Also I'm not sure what is the status of wxpropgrid stand alone anymore, probably I should talk to wx people.
oBFusCATed:
--- Quote from: MortenMacFly on December 18, 2011, 05:12:07 pm ---If you have time and nothing else to do ( ;D ;D ;D ) you may want to try to compile against wx 2.9.x. While in trunk this works after a few work-arounds, the debugger branch fails, but only due to the Editor stuff... :-(
--- End quote ---
Patches? I've given it 15minutes to try to make it compile but the changes are too much for me.
Do you use the normal codeblocks.cbp file or you're using the -wx29.cbp file? I'm try to compile it on linux and there is no -wx29.cbp file.
Also I've tried to hack the includes, but it didn't work, because of the `wx-config`stuff - it always takes precedence.
MortenMacFly:
--- Quote from: oBFusCATed on December 29, 2011, 10:23:43 pm ---Patches? I've given it 15minutes to try to make it compile but the changes are too much for me.
Do you use the normal codeblocks.cbp file or you're using the -wx29.cbp file? I'm try to compile it on linux and there is no -wx29.cbp file.
--- End quote ---
Too many of them and they are still WIP. I thought of creating another branch, so far I am using a heavily patched source tree with an own project file (the one with -wx29.cbp won't compile for 64 bit).
--- Quote from: oBFusCATed on December 29, 2011, 10:23:43 pm ---Also I've tried to hack the includes, but it didn't work, because of the `wx-config`stuff - it always takes precedence.
--- End quote ---
Well if should work if you play with the compiler/linker policies, even if you are using a script.
I don't know how we should handle it best... a 64 bit branch of the debugger branch / of trunk???
oBFusCATed:
--- Quote from: MortenMacFly on December 30, 2011, 07:47:20 am ---Too many of them and they are still WIP. I thought of creating another branch, so far I am using a heavily patched source tree with an own project file (the one with -wx29.cbp won't compile for 64 bit).
--- End quote ---
OK.
--- Quote from: MortenMacFly on December 30, 2011, 07:47:20 am ---Well if should work if you play with the compiler/linker policies, even if you are using a script.
--- End quote ---
The problem is that the `wx-config --cflags` is in other compiler settings and they are always used before the include search paths.
--- Quote from: MortenMacFly on December 30, 2011, 07:47:20 am ---I don't know how we should handle it best... a 64 bit branch of the debugger branch / of trunk???
--- End quote ---
Please don't do a branch of the branch, it will be a nightmare...
The best thing you can do is to fix trunk and then I'll try to fix the branch.
Maybe you can commit in trunk directly, so more people could test your changes.
MortenMacFly:
--- Quote from: oBFusCATed on December 18, 2011, 11:35:46 pm ---Also I'm not sure what is the status of wxpropgrid stand alone anymore, probably I should talk to wx people.
--- End quote ---
According to this:
http://sourceforge.net/projects/wxpropgrid/forums/forum/452254/topic/3959996
It seems the best way is to make use of the wx integrated version of wxPropGrid on the long run. Also, according to the SVN logs there seems not much active development on the stand-alone version of wxPropGrid recently.
Maybe you can contact the author of that component asking what to do best. I did a lot ugly #if wxCHECK_VERSION(2, 9, 0), but finally the wxPGRegisterEditorClass macro breaks it completely. I don't see a good way to overcome this. If you want to try, I can provide you with the wx 2.9.x project file I have / use which does not use the 64 bit compiler (I have three: one for wx 2.9.x/32 bit; one for wx 2.9.x/64 bit... and the "legacy" for wx 2.8.x/32 bit).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version