Code::Blocks on MacOSX

[bnilsson]

Code::Blocks for MacOSX now seems to be functional to the same level as on the other platforms.
I hope I will post the next message/support request on the "Using Code::Blocks" instead of "Help"!!!
Thank you all!!

[mandrav]

That's great news to hear
Thanks for insisting on making it work. I hope we can streamline the process in the not-so-distant future so others don't have to go through what you have gone through .
And thanks for bearing with us.

[Game_Ender]

Thats awesome news. bnilsson, does the current wiki page show the best way to get CB up and running on Mac OS X?

[takeshimiya]

Only if the MacIntel "can't run any program" show-stopper bug get's resolved it would be perfect.

So the current situation is:
MacOS X GTK port - PowerPC: more or less functional
MacOS X GTK port - Intel: more or less functional
MacOS X Carbon port - PowerPC: more or less functional
MacOS X Carbon port - Intel: non-functional due to mentioned bug
MacOS X Cocoa port - PowerPC: the wxWidgets Cocoa port is still inmature as far as I know
MacOS X Cocoa port - Intel: the wxWidgets Cocoa port is still inmature as far as I know

What can we do to fix the Carbon-Intel bug?

I've had bad luck when trying to debug C::B and couldn't debug it, mainly because the MacPorts dependencies got messed up easily (only upgraded the kernel), and couldn't built C::B anymore.

Just for the record, I created a little wxWidgets app that uses wxExecute() and it worked perfectly, so I don't think it's a Intel/wxWidgets issue. Even DialogBlocks works perfectly, which uses the same configuration.

Thats awesome news. bnilsson, does the current wiki page show the best way to get CB up and running on Mac OS X?

I can answer that: yes. The easiest way is to use a nightly build (it's even easier than on other systems), and for compiling it, the easiest way is to use MacPorts.

It would be nice if the afb patches get applied because they often go out-of-sync and can't merge.

[Game_Ender]

I have had trouble with wxExecute on the Mac OS X intel.  I thought it was very strange too.  Can you post the test program, I would be able to test it tomorrow.

[bnilsson]

I was maybe a little too quick to announce total MacOSX success, one remaining issue is wxSmith.
The current version is consuming most of the available memory when opening a .wxs file, this is now a known problem for MacOSX.
As a Mac owner, I have offered byo that I look into it, but due to my very limited experience in wx programming I expect it to take (long) time. If anyone with a Mac and more experience in the subject I would encourage involvement.

[afb]

It would be nice if the afb patches get applied because they often go out-of-sync and can't merge.

The important ones is fixing "bootstrap" and "configure", so that they work out of the box on Mac OS X (without patching). This includes allowing to specify different autotools versions, and making the plugin bundles link without missing symbols...

The wxFlatNotebook patch is upstream, so that should be on it's way for like wxFNB 2.2 or something and make it into Code::Blocks that way. The fixes for GTK+ on Darwin would be nice to have, but do I think most people want the Carbon version.

[mandrav]

I was maybe a little too quick to announce total MacOSX success, one remaining issue is wxSmith.

wxSmith has issues in other platforms too, so don't worry. Eventually, byo will fix it .

[afb]

I was maybe a little too quick to announce total MacOSX success, one remaining issue is wxSmith.

wxSmith would be nice to have, but I think it can wait until the rest works better...

Ones that I would like to see are:

• Fixing the execute bugs on Intel, so that it doesn't just "hang" the first thing
• Fixing the debugger interaction so that it finds source and doesn't self-destruct
• Double-clicking files in Finder to open them, instead of having to use Open
• Working links on the Start Here page, and it not first showing up as all blank
• Making Run start a new Terminal.app session (by using AppleScript, probably)
• Installation package for wxWidgets development files (I am working on this)

That, and I would also like a pony full support for the D programming language :-)

[bnilsson]

This is the bootstrap I use on my Mac, working satisfactory for me.
It requires MacPort autotools.

Code

# ! / bin / sh

# stolderdized from Ogre3D (www.ogre3d.org)

# Check for proper versions of autotools
# We require:
#  - autoconf 2.50+
#  - automake 1.7+
#  - libtool 1.4+

# Touch revision.m4
if [ -f ./update_revision.sh ]; then
	./update_revision.sh;
elif [ ! -f ./revision.m4 ]; then
	echo "m4_define([SVN_REVISION], trunk-r0)" > ./revision.m4;
fi

# Deal with some gentoo-specific issues
export WANT_AUTOMAKE='1.7'
export WANT_AUTOCONF='2.5'

## Using prereq in autoconf rather than here, mostly for the debian systems at
## this point
if test -n "`/opt/local/bin/autoconf --version 2>&1|head -n 1|egrep '1.*|2.[0-4]'`"; then
	echo "Autoconf 2.50 or above is required. Aborting build...";
    exit 1;
fi

if test -n "`/opt/local/bin/automake --version 2>&1|head -n 1|egrep '1.[0-6]'`"; then
	echo "Automake 1.7 or above is required. Aborting build...";
	exit 1;
fi

if test -n "`/opt/local/bin/glibtool --version 2>&1|head -n 1|cut -f 4 -d ' '|egrep '1.[0-3]'`"; then
	echo "Libtool 1.4 or above is required. Aborting build...";
	exit 1;
fi

# clean up files which cause confusion when switch versions of auto*
rm -rf autom4te.cache

# Fire up autotools
/opt/local/bin/glibtoolize --force --copy && \
	/opt/local/bin/aclocal $ACLOCAL_FLAGS && \
	/opt/local/bin/autoheader && \
	/opt/local/bin/automake --include-deps --add-missing --foreign --copy && \
	/opt/local/bin/autoconf 

About the debugger: If there are no spaces in the path, it seems to find the source files. Is it more problems than this?

[afb]

What can we do to fix the Carbon-Intel bug?

Company has invested in an Intel mac, so I'll be hacking away at it in my spare time.

[afb]

This is the bootstrap I use on my Mac, working satisfactory for me.
It requires MacPort autotools.

You shouldn't need to hardcode the /opt/local prefix like that ?

Here is what I use for DarwinPorts:

Code

pre-configure {
	reinplace "s|^libtoolize|glibtoolize|" \
		"${worksrcpath}/bootstrap"
	reinplace "s|aclocal$|aclocal -I ${prefix}/share/aclocal|" \
		"${worksrcpath}/bootstrap"
}
configure.cmd   ./bootstrap && ./configure

For regular Mac OS X, all it needs is first searching for
the autoconf-2.57 and automake-1.7 and glibtool variants ?
(before falling back to just "autoconf", "automake", "libtool")

Making them variables is also a workable solution, as suggested:
http://developer.berlios.de/patch/?func=detailpatch&patch_id=1502&group_id=5358

[bnilsson]

I am sure you are right, I just wanted to demostrate a working example, not necessarily a good example.
In case you haven't noticed, I am only an amateur c++ programmer, but a complete novice in shell scripts. 
I will try your script and see if it is working for me too.

[afb]

I am sure you are right, I just wanted to demostrate a working example, not necessarily a good example.
In case you haven't noticed, I am only an amateur c++ programmer, but a complete novice in shell scripts. 
I will try your script and see if it is working for me too.

I should note that the snippet was from the Portfile for MacPorts,
and thus it is written in tcl. Your bootstrap probably works fine,
but I'm looking for a solution that would work OK everywhere...
(i.e. there should be no need for the C::B user to tinker with it)

But if you are using MacPorts, those two "substitutions"
should be all you need to the regular bootstrap file from C::B ?

Code

s|^libtoolize|glibtoolize|
s|aclocal$|aclocal -I ${prefix}/share/aclocal|

Sometimes I post the development solutions in the User forum,
sorry about that in advance, and do ask if anything is unclear...

[afb]

To clarify, those substitions are to be made to the file itself -
they are not shell commands. s/foo/bar/ means to replace...

This might give some more info: http://en.wikipedia.org/wiki/Sed
But none of this should be needed, once "bootstrap" is fixed...

[byo]

I was maybe a little too quick to announce total MacOSX success, one remaining issue is wxSmith.

wxSmith has issues in other platforms too, so don't worry. Eventually, byo will fix it .

Linux may be easy thing but is there any way to emulate Mac behaviour ? I tried to fix some bugs but it still takes 2GB of memory:/

[afb]

Linux may be easy thing but is there any way to emulate Mac behaviour ?

I'm afraid you'll have to use a Mac.

[Game_Ender]

I am just curious Byo what are you doing in your plugin that is so platform dependent?  Are these bugs arsing from the lack of wxWidgets documentation on features which do different things depending on different platforms?

[takeshimiya]

I am just curious Byo what are you doing in your plugin that is so platform dependent?  Are these bugs arsing from the lack of wxWidgets documentation on features which do different things depending on different platforms?

Usually is just a bug that in some platform (Windows) goes unnoticed or doesn't happens while it appears on others (Linux/Mac).
AFAIK wxSmith doesn't uses non-cross platform code.

Has anyone tried valgrind (It even exists there?) on Mac? or any equivalent?
And debugging it?

Anyways the issues raised by afb haves more priority than wxSmith currently.

[Game_Ender]

Has anybody run valgrind over CB on Linux recently?  Valgrind is being ported to mac, we just half to wait.

[byo]

I am just curious Byo what are you doing in your plugin that is so platform dependent?  Are these bugs arsing from the lack of wxWidgets documentation on features which do different things depending on different platforms?

It's system used in editor to draw over widgets (f.ex. adding these black boxes around item allowing to resize / move them). I've tried to handle repaint events for all widgets in edited resource but it wasn't enough (and to be more clear: wxWidgets is really buggy in handling of paint/mouse events for standard widgets). So currently I do some trick - I paint all items and after it's done I fetch picture directly from screen, hide items and use that fetched picture as background for editor. It's hard to do make some universal technique but I believe it's donnable.

Other things are incompatibilities in raising events. I don't remember exactly but after setting some text on item manually it raises text-changed event on some platforms and doesn't on other. So it may work on windows but may fail on linux etc.

Anyways the issues raised by afb haves more priority than wxSmith currently.

True, wxSmith is not required to make C::B running.
But it doesn't mean I will stop porting wxSmith .

[Game_Ender]

This is quite a hack you have there.  Sorry to hear the wxWidgets is in a such a state that it requires you to do that.  I wonder how DialogBlocks does it?  I always assumed there was just a special version of each standard widget that drew a rectangle around its border with during the proper paint event.

[tiwag]

.... So currently I do some trick - I paint all items and after it's done I fetch picture directly from screen, hide items and use that fetched picture as background for editor...

that's maybe the reason why i do most of the time only see a black box instead of the created dialogue  :?