Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Will patches to compile and link C::B against wxWidgets 2.7.1 be accepted?
takeshimiya:
--- Quote from: afb on November 02, 2006, 06:57:31 pm ---Fair enough, let's move them to the Mac locations (I think wx has some helpers)
MacPorts normally installs in /opt/local, though - but let's not mix that in here...
--- End quote ---
Yes I know sorry for the copy-paste
--- Quote from: afb on November 02, 2006, 06:57:31 pm ---I had planned to separate it, in order to cut down the size of the nightly and also in order for the user to be able to develop new program for wxWidgets with it ?
--- End quote ---
separated for nightly builds, joined for stable releases,
--- Quote from: afb on November 02, 2006, 06:33:13 pm ---It definitely is, and they can also put it in ~/Library/Frameworks and ~/Applications if they do not have admin priviledges on the machine ?
--- End quote ---
of course,
--- Quote from: afb on November 02, 2006, 06:33:13 pm ---MacPorts will install in /Applications/DarwinPorts and /opt/local, all according to their guidelines.
--- End quote ---
I know, sorry for the copy-paste again; I wonder if the guidelines will change to MacPorts, I think /Applications/*Ports it's good nonetheless for the sake of symlinks, just when using MacPorts.
afb:
--- Quote from: takeshi miya on November 02, 2006, 07:23:04 pm ---
--- Quote from: afb on November 02, 2006, 06:57:31 pm ---I had planned to separate it, in order to cut down the size of the nightly and also in order for the user to be able to develop new program for wxWidgets with it ?
--- End quote ---
separated for nightly builds, joined for stable releases,
--- End quote ---
Yes. But that should be as simple as moving it inside the bundle, thankfully...
i.e. include wx as CodeBlocks.app/Contents/Frameworks/wxWidgets.framework
(I think will be using wxWidgets.framework, rather than wx.framework)
--- Code: ---#include <wxWidgets/wxWidgets.h>
--- End code ---
The usual <wx/wx.h> will work too, with a little wx -> . symbolic link
inside and a -I/Library/Framework/wxWidgets.framework/Headers flag...
--- Quote ---
--- Quote from: afb on November 02, 2006, 06:33:13 pm ---It definitely is, and they can also put it in ~/Library/Frameworks and ~/Applications if they do not have admin priviledges on the machine ?
--- End quote ---
of course,
--- End quote ---
Mac OS X users normally run as admin, but I converted my own user account...
Will continue with the simple ZIP for a while, maybe convert to DMG for stable ?
And the user can just move the framework and application to where they want it.
takeshimiya:
--- Quote from: afb on November 02, 2006, 07:42:56 pm ---Yes. But that should be as simple as moving it inside the bundle, thankfully...
--- End quote ---
Great
--- Quote from: afb on November 02, 2006, 06:33:13 pm ---Will continue with the simple ZIP for a while, maybe convert to DMG for stable ?
--- End quote ---
Or both, I have seen lots of .dmg.gz and .dmg.zip;
besides, the dmg format supports being compressed in zip from 10.1 or so, and bz2 from 10.4
stahta01:
They are talking about releasing wxWidgets 2.7.2 on Friday, tomorrow, at 0900 GMT; I think this is 0400 EST. Edit: Person asked them to hold off till Monday so he/she could finish some task.
Note: I have given up on 2.7.1 because the docs have not been updated enough on wxDialog for me to figure out the changes in the wx27 code and how to patch C::B.
Edit: Found suggestion that pointed me in the correct direction to get 2.7.1 to compile & link.
Note: I am working on getting the patches ready for C::B for wxWidgets 2.7.0; I still testing changes for problems with 2.63p2, having issues with the SVN changing for the files I am patching. I have decided to break my patch into 4 (plus 1 for 2.7.1) small patches. ( 5 total files involved in all patches for 2.7.0 and 2 files for 2.7.1 for now.)
Patch 1 for 2.7.0 uploaded to BerliOS see https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1617&group_id=5358
Patch 2 for 2.7.0 uploaded to BerliOS see
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1618&group_id=5358
Patch 3 for 2.7.0 uploaded to BerliOS see
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1619&group_id=5358
Patch 4 for 2.7.0 uploaded to BerliOS see
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1620&group_id=5358
Patch 1 for 2.7.1 uploaded to BerliOS see https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1621&group_id=5358
Tim S
stahta01:
NOTE: You must be building codeblocks from SVN for these directions to work.
NOTE: You have to know how to use "patch -u" with unified patches.
NOTE: This build is NOT SUPPORTED by the CodeBlocks Team!
NOTE: This ONLY makes it compile & Link against wxWidgets!
NOTE: There is NO warranty that it will run let alone work right!
Extract wxWidgets-2.7.0-1 to folder.
in file include\wx\msw\setup.h
enable WXWIN_COMPATIBILITY_2_4 like below.
#define WXWIN_COMPATIBILITY_2_4 1
[IMHO, this is a work around that should NEVER be done for production code
because it breaks the ABI, so use the DLL created for private use only.
The wxWidgets-2.7.0-1 folder with modified wx/treebase.h should only be
included for private use only projects.]
in file wx/treebase.h add "0 // " to line 73 like below
#if 0 // WXWIN_COMPATIBILITY_2_4
Below is the command I used to build; SEE files in docs\msw for windows building help
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1
Remember to copy the DLL to your C::B folder.
Apply the Patches for 2.7.0; you can also apply the Patch for 2.7.1.
Build C::B
NOTE: You must be building codeblocks from SVN for these directions to work.
NOTE: You have to know how to use "patch -u" with unified patches.
NOTE: This build is NOT SUPPORTED by the CodeBlocks Team!
NOTE: This ONLY makes it compile & Link against wxWidgets!
NOTE: There is NO warranty that it will run let alone work right!
Tim S
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version