Will patches to compile and link C::B against wxWidgets 2.7.1 be accepted?

[takeshimiya]

Here are the file sizes, for your amusement:

 42M    CB_20061101_rev3164_macx86.tar
 18M    CB_20061101_rev3164_macx86.tzo

 14M    CB_20061101_rev3164_macx86.tgz
 13M    CB_20061101_rev3164_macx86.tbz

 14M    CB_20061101_rev3164_macx86.zip
8.9M    CB_20061101_rev3164_macx86.7z

:lol:

"Better" maybe, but it's not the Mac way... :-)

There are apps out there that are bundle but separated by archs,

Hmm, the Xcode 2.4.1 security update weighs in at.... 932.2MB.
So I don't think 13M or 14M will make a difference to Mac users.  :-D

I think it's totally ok for stable releases but,
it's a bit too much for nightly builds, I don't know if you, but maybe other will be setting up nightly builds, this means everyday downloads,
and also accounting that berlios still doesn't support resume, there are people that still cares about the size, which are probably still on dial up or at a univ/work capped connection

Thanks for the upload! I'm going to test as soon as I can

[afb]

There are apps out there that are bundle but separated by archs,

Actually it was a bit of fuss to "lipo" it together, so taking it apart would be easy...

I think it's totally ok for stable releases but,
it's a bit too much for nightly builds, I don't know if you, but maybe other will be setting up nightly builds, this means everyday downloads,
and also accounting that berlios still doesn't support resume, there are people that still cares about the size, which are probably still on dial up or at a univ/work capped connection

The zip is 8M when "thin". But then I need a second one for PPC, and educate people which is which and so on. The "fat" (now: Universal) binary is at least very simple to use...

I think the MacPorts option would be better if you are bandwidth challenged.

Code

6.3M    codeblocks-1.0_0+macosx.i386.tgz

[afb]

One thing that we could do, is link it to a /Library/Frameworks/wxWidgets.framework
The plus side of that is that it also provides the developer files and not just the libs ?

The down side is that we would have to make such a wx framework,
and make sure that it is the right version and has the right patches...

[takeshimiya]

The down side is that we would have to make such a wx framework,
and make sure that it is the right version and has the right patches...

Actual versions come with 2.5.x I think, and Leopard will come with 2.8 out of the box if nothing goes wrong,
however users of previous Mac OS X will be not benefited; and this will also mean to have different packages for pre 10.5 and post 10.5

[afb]

There is no wxWidgets.framework. Tiger ships with wxPython 2.5 - as libraries.
I think that Leopard would be better off with wxPython 2.7 as libraries too, but...

If they want to rename wx 2.7.3 as 2.8.0 to include it with that OS that's OK,
but it probably just means that we have to provide 2.8.1 as a package instead ?

I have built such a framework though, it just hasn't been officially included.
For details you can see some scribblings at http://www.algonet.se/~afb/wx/

Haven't decided if it's going to be the "pretty" wxWidgets.framework or the
more "usable" wx.framework. But I guess the wx crew will ultimately decide.

SDL has the same problems when running on Mac OS X.
"To framework, or not to framework, that is the question..."

[takeshimiya]

There is no wxWidgets.framework. Tiger ships with wxPython 2.5 - as libraries.
I think that Leopard would be better off with wxPython 2.7 as libraries too, but...

I see, also probably it's not worth using what the system haves, as you have more control on which wx version to use;
about the other thing, it probably depends if you are more on the BSD side or the Apple side of Mac

[takeshimiya]

Hi,

The 3164 build is uploaded to BerliOS now

I've tried the build and it worked, I could compile for the first time from CB
Of course there are a lot of little/medium issues still, but it at least serves as a build system,

The first thing I found is that I couldn't run C::B because some previous setting in default.conf was bad,
and here comes the problem: the file is located in ~/.codeblocks, so I didn't have any way to access it (not from Finder nor terminal). I know that some programs let's you enable "see hidden files" but it's not the point and I didn't have one at hand,

I propose to use APPDATA as ~/Library/Application Support/CodeBlocks/ which is what most crossplatform/opensource programs are using (non-crossplatform programs tend to use ~/Library/Preferences because they don't have problems in using the plist format),

The other problem is when compiling, I get occasionally this error Message box (it gets compiled nonetheless):
can't flush file descriptor 16 (error 45: Operation not supported)

[afb]

I prefer to use the cross-platform locations like /usr/local/lib/libwx_mac-2.6.dylib and ~/.codeblocks, but I can probably be talked into changing those to /Library/Frameworks/wxWidgets.framework and ~/Library/Application\ Support/CodeBlocks to work with the venerable Finder...

I still suggest /Developer/Applications/CodeBlocks.app as the location for the program. (that is, what use to be /usr/local/bin/codeblocks) Some of the wizards also needs to be redone to understand frameworks, such as the ones for OpenGL/GLUT and wxWidgets...

[takeshimiya]

I prefer to use the cross-platform locations like /usr/local/lib/libwx_mac-2.6.dylib and ~/.codeblocks,

Those are "unix" locations, in Windows you have them in C:\Program Files\CodeBlocks\wxmsw26u_gcc_cb.dll (usually) and %APPDATA%\codeblocks,
in Mac I also like to have libraries in /usr/local/lib/ (because I use MacPorts), but for bundles (.app) it would be ugly to have them in /usr/local/bin and similar places.

but I can probably be talked into changing those to /Library/Frameworks/wxWidgets.framework

It's also fine as currently, if the mac dylib is inside the bundle,

I still suggest /Developer/Applications/CodeBlocks.app as the location for the program.

Yeah, it's more standard than /Applications in this case and /Developer/Applications is more well suited (Xcode is there),
however since C::B is distributed as a bundle, that's a users choice,

(that is, what used to be /usr/local/bin/codeblocks)

I think that location can be fine if you build it from MacPorts, but /Developer/Applications is fine too,

Some of the wizards also needs to be redone to understand frameworks, such as the ones for OpenGL/GLUT and wxWidgets...

Yes, there's a lot of work to be done

[afb]

Those are "unix" locations, in Windows you have them in C:\Program Files\CodeBlocks\wxmsw26u_gcc_cb.dll (usually) and %APPDATA%\codeblocks,
in Mac I also like to have libraries in /usr/local/lib/ (because I use MacPorts), but for bundles (.app) it would be ugly to have them in /usr/local/bin and similar places.

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...

but I can probably be talked into changing those to /Library/Frameworks/wxWidgets.framework

It's also fine as currently, if the mac dylib is inside the bundle,

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 ?

I still suggest /Developer/Applications/CodeBlocks.app as the location for the program.

Yeah, it's more standard than /Applications in this case and /Developer/Applications is more well suited (Xcode is there),
however since C::B is distributed as a bundle, that's a users choice,

It definitely is, and they can also put it in ~/Library/Frameworks and ~/Applications if they do not have admin priviledges on the machine ?

(that is, what used to be /usr/local/bin/codeblocks)

I think that location can be fine if you build it from MacPorts, but /Developer/Applications is fine too,

MacPorts will install in /Applications/DarwinPorts and /opt/local, all according to their guidelines. The stuff in /Applications/WhateverPorts will be symlinks or scripts that use the regular installation (it just allows for easier access).

[takeshimiya]

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...

Yes I know sorry for the copy-paste

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 ?

separated for nightly builds, joined for stable releases,

It definitely is, and they can also put it in ~/Library/Frameworks and ~/Applications if they do not have admin priviledges on the machine ?

of course,

MacPorts will install in /Applications/DarwinPorts and /opt/local, all according to their guidelines.

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]

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 ?

separated for nightly builds, joined for stable releases,

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>

The usual <wx/wx.h> will work too, with a little wx -> .  symbolic link
inside and a -I/Library/Framework/wxWidgets.framework/Headers flag...

It definitely is, and they can also put it in ~/Library/Frameworks and ~/Applications if they do not have admin priviledges on the machine ?

of course,

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]

Yes. But that should be as simple as moving it inside the bundle, thankfully...

Great

Will continue with the simple ZIP for a while, maybe convert to DMG for stable ?

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