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

[afb]

Found the code in src/mac/corefoundation/utilsexc_cf.cpp.
They set up a background thread to poll for process termination.

Doesn't look impossible to backport, maybe we can even add it
as an add-on outside of patching the main wxWidgets library ?

[afb]

Yup, that was it! I guess it could at least make it into a wx 2.6.3pl3,
if there shouldn't be any more "real" 2.6 releases for some reason ?

Here it is, anyway:
http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

[takeshimiya]

Found the code in src/mac/corefoundation/utilsexc_cf.cpp.
They set up a background thread to poll for process termination.

Doesn't look impossible to backport, maybe we can even add it
as an add-on outside of patching the main wxWidgets library ?

Yes it would be possible (cbExecute() or something like), however I prefer instead not wait for that and have a working C::B now, and at a later time, due to Tim patches use the 2.8 branch which contains lots and lots of improvements for Mac

[takeshimiya]

Yup, that was it! I guess it could at least make it into a wx 2.6.3pl3,
if there shouldn't be any more "real" 2.6 releases for some reason ?

Here it is, anyway:
http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

That's really great,
one last thing, can you upload a dmg to berlios? I can't wait to use it finally

[thomas]

One reason might be that wxExecute hangs on Mac OS X Intel
using wx 2.6.3, while it works just fine when using wx 2.7.1...

On second thought this is a lame reason. Might as well work
around the bug on wx 2.6.3, or wait until the 2.6.4 release...

On a third thought, we might not use wxExecute at all any more...

[afb]

Working on a new nightly build, will upload when finished.
(finally getting around to scripting the sucker build process)

I will probably continue to use ZIP instead of DMG, though.
Something about open source and closed formats, I guess.

[afb]

Code

------------- Build: Debug in HelloWorld ---------------
Compiling: main.c

Linking console executable: ./HelloWorld

Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings

No changes to Code::Blocks were needed...

[afb]

Patch submitted to the wx crew for consideration for wx 2.6.3pl3 / 2.6.4...

https://sourceforge.net/tracker/?func=detail&atid=309863&aid=1588883&group_id=9863

[stahta01]

I have patched C::B SVN 3163 with my own patches enough to get it to compile, link and boot against wxWidgets 2.7.0 ( with changes to code [treebase.h] in wxWidgets in addition to code in C::B ).

I used it to compile itself as my test of if it works enough to be slightly useful.

Note: I am using wx/setup.h with
#define WXWIN_COMPATIBILITY_2_4 1
#define WXWIN_COMPATIBILITY_2_6 1

I am now going to try using wx/setup.h with
#define WXWIN_COMPATIBILITY_2_4 0         Edit: This setting is beyond my knowledge level at this time.

Tim S

[takeshimiya]

Working on a new nightly build, will upload when finished.
(finally getting around to scripting the sucker build process)

I will probably continue to use ZIP instead of DMG, though.
Something about open source and closed formats, I guess.

or .tar.bz2 / .dmg.bz2 as it compresses better, and .dmg would be for stable releases

No changes to Code::Blocks were needed...

Patch submitted to the wx crew for consideration for wx 2.6.3pl3 / 2.6.4...

https://sourceforge.net/tracker/?func=detail&atid=309863&aid=1588883&group_id=9863

So as you might have read, there are chances of a 2.6.4, but I'm waiting more for 2.8 

I have patched C::B SVN 3163 with my own patches enough to get it to compile, link and boot against wxWidgets 2.7.0

[afb]

or .tar.bz2 / .dmg.bz2 as it compresses better, and .dmg would be for stable releases

Hardly worth the enormous processing time / memory usage difference, though.

Code

 13M    CB_20061101_rev3164_macx86.tbz
 14M    CB_20061101_rev3164_macx86.zip

Especially not when considering that 50% of that is a redundant arch, and 60% is wx ?

So as you might have read, there are chances of a 2.6.4, but I'm waiting more for 2.8 

I'm not holding my breath... Waited a month for the MacPorts guys to drop a single --with-mac line from the wxWidgets port (which isn't happening), so I'm on a build-it-myself streak.

Will fix the DarwinPorts version so that you can have both wxMac and wxGTK installed at the same time, which basically is just about doing up a Port for wxBase for them to share...

[takeshimiya]

Hardly worth the enormous processing time / memory usage difference, though.

 13M    CB_20061101_rev3164_macx86.tbz
 14M    CB_20061101_rev3164_macx86.zip

Strange, it usually gives a noticeable improvement; make sure you compress with "solid mode" ON or whatever is called,

Especially not when considering that 50% of that is a redundant arch, and 60% is wx ?

I think that's ok with stable releases, but for nightly builds and to save space I think that separating archs is better,
about wx, only if it can be separated from C::B like windows' nightly builds (although it might confuse new users)

So as you might have read, there are chances of a 2.6.4, but I'm waiting more for 2.8 

I'm not holding my breath... Waited a month for the MacPorts guys to drop a single --with-mac line from the wxWidgets port (which isn't happening), so I'm on a build-it-myself streak.

Will fix the DarwinPorts version so that you can have both wxMac and wxGTK installed at the same time, which basically is just about doing up a Port for wxBase for them to share...

that's a bit sad, but this happens with most 'distros'

[afb]

one last thing, can you upload a dmg to berlios? I can't wait to use it finally

The 3164 build is uploaded to BerliOS now, think it should match the previous ?
(it does have some build patches and icons in addition to all the rest of them...)

[afb]

Strange, it usually gives a noticeable improvement; make sure you compress with "solid mode" ON or whatever is called,

I don't think bzip2 has a "solid mode", at least I couldn't find one in 1.0.2 ?

Here are the file sizes, for your amusement:

Code

 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

We could do a .dmg for the final release, it's the same as tgz + the all HFS+ overhead.

I think that's ok with stable releases, but for nightly builds and to save space I think that separating archs is better,
about wx, only if it can be separated from C::B like windows' nightly builds (although it might confuse new users)

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

The way that it is going to be is:
Mac OS X -> Universal and Bundled
MacPorts -> split up by arch and lib

Not sure if I mentioned it, but besides wxWidgets the Mac OS X version also bundles a static version of libpng, libjpeg, libtiff, and expat...

the "macppc" builds on BerliOS are all for Panther, by the way.
the "macx86" are all Universal, but BerliOS doesn't have that arch.

[afb]

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