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 Select Expand

# ! / 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 Select Expand


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 Select Expand


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