Release 16.01 for Mac

[dkulp]

I stuck an experimental OSX build up at:

http://dankulp.com/xlights/CodeBlocks-MAC-16.1.tar.gz

This is using a custom build of wxWidgets 3.0.x  which is the latest code from git + a bunch of fixes that I submitted back to them in a pull request.   It also contains some fixes to Code::Blocks to get it working on MAC, particularly finding plugins with the ".app" as well as some fixes for Retina displays.   Not all those fixes are submitted back yet.

Very minimal testing has been done as I pretty much just use it for wxSmith.

[Easior Lars]

I stuck an experimental OSX build up at:

http://dankulp.com/xlights/CodeBlocks-MAC-16.1.tar.gz

I had a try of your tarball on Mac OS Yosemite. However, there's no lucky for me since your build requires Mac OS X 10.11 or later. Can you change your build SDK to OS X 10.10 or lower.

[dkulp]

I stuck an experimental OSX build up at:

http://dankulp.com/xlights/CodeBlocks-MAC-16.1.tar.gz

I had a try of your tarball on Mac OS Yosemite. However, there's no lucky for me since your build requires Mac OS X 10.11 or later. Can you change your build SDK to OS X 10.10 or lower.

Can you give it another try?   I added the -mmacosx-version-min=10.7 flag to all the compiles/links which hopefully fixes that.   However, there are still a couple of plugins that won't load as I need to figure out how to pass some more link flags to them so they have enough space in the header to adjust the paths to the libs.   Something for tomorrow.  However, if you can at least see if CodeBlocks starts up, that would be a great start.

[MortenMacFly]

Can you give it another try?   I added the -mmacosx-version-min=10.7 flag to all the compiles/links which hopefully fixes that.   However, there are still a couple of plugins that won't load as I need to figure out how to pass some more link flags to them so they have enough space in the header to adjust the paths to the libs.   Something for tomorrow.  However, if you can at least see if CodeBlocks starts up, that would be a great start.

That's great stuff!

BTW: If you have built a working C::B, you could use C::B to build C::B and then the script mac_pack in the "src" folder. this way, all plugins should be fine (at least they were last time) and it makes a proper app package.

Any patches towards making this work are most welcome. We are hardly seeking Mac devs.

[dkulp]

Can you give it another try?   I added the -mmacosx-version-min=10.7 flag to all the compiles/links which hopefully fixes that.   However, there are still a couple of plugins that won't load as I need to figure out how to pass some more link flags to them so they have enough space in the header to adjust the paths to the libs.   Something for tomorrow.  However, if you can at least see if CodeBlocks starts up, that would be a great start.

That's great stuff!

BTW: If you have built a working C::B, you could use C::B to build C::B and then the script mac_pack in the "src" folder. this way, all plugins should be fine (at least they were last time) and it makes a proper app package.

Any patches towards making this work are most welcome. We are hardly seeking Mac devs.

I've had very little luck getting it to build from within CB.   Lots of flags need changing since I'm using clang and not gcc.   I just discovered the field that you edit compiler flags in CB is changing all the -- to a single long hyphen which then breaks everything so I have to edit everything in the raw XML.

The mac_pack is only semi-usable.   I'm not using a monolithic wxwidgets so those parts are problematic.  Also, when building from the command line, all the plugins get a .so extension, not .dylib.   Apparently building from CB makes .dylibs which is interesting.  In anycase, I have a similar mac_pack script that I'm using to try and assemble it.   The problem right now is that a few of the plugins don't have enough "space" in their header to allow for modifications.   You get an error:

Code

 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: changing install names or rpaths can't be redone for: /Users/dkulp/tmp/CodeBlocks.app/Contents/Resources/share/codeblocks/plugins/libautosave.so (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)

so that's next to try and figure out.   Most of the plugins work fine, just a few have this issue.

[MortenMacFly]

so that's next to try and figure out. Most of the plugins work fine, just a few have this issue.

Darn... I never understood why its so damn hard for an App package to get it right in the first place.

And the dylib issue: In the C::B project, we use the "auto-postfix" feature, this work nice, usually.

I'm afraid I can't help much here. I used to install XCode, then GCC and then build it using GCC before I abandoned Mac. I've never used clang on the Mac, but I am aware that this should be the default now.

Whatever you get - please keep in mind what you changed so we can feed it into the repo. If unsure, you could also dump an archive of the while C::B sources / binaries after it built correctly.

Oh - and are you using wx30 then? Make sure you do the wxSmith stuff correctly in that case. Because not all is wx30 compatible. Some libs are in the wx source tree now and don't need to be compiled for the C::B wx30 version. Thats also why I said use C::B to compile C::B becasue the wx30 project files are correct.

[Easior Lars]

I've had very little luck getting it to build from within CB.   Lots of flags need changing since I'm using clang and not gcc.   I just discovered the field that you edit compiler flags in CB is changing all the -- to a single long hyphen which then breaks everything so I have to edit everything in the raw XML.

The mac_pack is only semi-usable.   I'm not using a monolithic wxwidgets so those parts are problematic.  Also, when building from the command line, all the plugins get a .so extension, not .dylib.   Apparently building from CB makes .dylibs which is interesting.  In anycase, I have a similar mac_pack script that I'm using to try and assemble it.

A few months ago, I have done some work about CB compiled by clang and got a cbp or workspaces file to bootstrap C::B. Some modifications of mac_pack were also done. If it was useful to you, I can sent it to you by email. But your patches of C::B  on Mac OS are more interesting for me.

[oBFusCATed]

Why don't just directly post the changes as a patch in this topic?

[Easior Lars]

Why don't just directly post the changes as a patch in this topic?

Ok. I'm afraid that my patch is not full of testing. Please use it in your own risk. Some dependencies on GTK+ should be removed.

[MortenMacFly]

Ok. I'm afraid that my patch is not full of testing. Please use it in your own risk. Some dependencies on GTK+ should be removed.

Good starting point do far... 3 questions:
* Did you try to do a re-build with these project files under Mac? does it work?
* Do you have a workspace file that covers all project files?
* Why did you change update30 script, esp. removing the optional tools? This should actually work...

[Easior Lars]

* Did you try to do a re-build with these project files under Mac? does it work?

Yes, it works on Mac OS Yosemite. But bugs should be fixed. Dan Kulp's pacthes are necessarily needed.

* Do you have a workspace file that covers all project files?

I have a workspace file named by CodeBlocks_wx30-mac.workspace, it also works well.

* Why did you change update30 script, esp. removing the optional tools? This should actually work...

Because the same scripts have been added to the corresponding cbp files, e.g. lib_finder_wx30-mac.cbp, etc.

I have made some modifications on my patch today. Please see this attachment.

Final modification of my patch is attached. It's time to Dan Kulp's patches to fix long-time standing bugs on Mac OS.

[dkulp]

It's a shame that CB isn't on GitHub and we could just submit pull pull requests...

I've attached my changes to the src tree.   They pretty much fall into three categories:

1) Retina support - wxsdrawingwindow.cpp needs a bunch of changes to work properly on Retina screens.   That said, this ALSO requires a bunch of patches to wxWidgets which have been submitted there.   My fork of wxWidgets has the needed fixes:

https://github.com/dkulp/wxWidgets/tree/WX_3_0_BRANCH

2) Plugin loading - when building from command line and running "make install", plugins are in a different place and named differently than when built form within CB and/or packaged in an app.   The patch tries to account for the various options.

3) Minor startup performance thing - for some reason (not sure why), a bunch of the png files are being copied during make install which is causing wxImage to not be valid which takes a second per image to generate a stack trace.  Ideally, I'd fix the image copying, but for now, if the image is no OK, use a null bitmap.

[MortenMacFly]

It's a shame that CB isn't on GitHub and we could just submit pull pull requests...

C::B is on GitHub, e.g. here:
https://github.com/obfuscated/codeblocks_sf

This is regularly sync'd with the "golden" SVN repo. So you can provide pull requests if you explain and talk to obfuscated the developer behind this GIT repo clone.

I'll do my best to collect all Mac related stuff, nag me if you miss anything. For now, I am collecting until you tell that's really it an it works. For the moment I see version coming everyday, so I won't commit until its kind of final.

One thing please notice: Try to avoid to change code or scripts that may affect other platforms, especially Linux. Or, if you have to, please state explicitly what function needs to be tested on other platforms. You can freely add new scripts (like update30_mac), of course.

Also, please state for what build the patch is for. Keep in mind that on the Mac you'll have two options: Building with autotools or with C::B itself. Its easier to understand your changes if you mention the target build system.

[oBFusCATed]

The current workflow doesn't support the typical pull-request workflow, because of svn<->git/git svn limitations.
In order for some branch to be committed in svn it needs to be rebase-able on the master branch. If you fulfil this requirement, I can commit such branches.

[Easior Lars]

It's a shame that CB isn't on GitHub and we could just submit pull pull requests...

I've attached my changes to the src tree.   They pretty much fall into three categories:

1) Retina support - wxsdrawingwindow.cpp needs a bunch of changes to work properly on Retina screens.   That said, this ALSO requires a bunch of patches to wxWidgets which have been submitted there.   My fork of wxWidgets has the needed fixes:

https://github.com/dkulp/wxWidgets/tree/WX_3_0_BRANCH

2) Plugin loading - when building from command line and running "make install", plugins are in a different place and named differently than when built form within CB and/or packaged in an app.   The patch tries to account for the various options.

3) Minor startup performance thing - for some reason (not sure why), a bunch of the png files are being copied during make install which is causing wxImage to not be valid which takes a second per image to generate a stack trace.  Ideally, I'd fix the image copying, but for now, if the image is no OK, use a null bitmap.

Hi, Dan! I have made another try to build CB on Mac OS by merging your patches into CB source tree. My steps are as follows:

Code: bash

$ git clone https://github.com/wxWidgets/wxWidgets.git -b WX_3_0_BRANCH --depth=1
$ cd wxWidgets
$ mkdir cocoabuild && cd cocoabuild
$ ../configure --enable-monolithic --with-macosx-version-min=10.7 --enable-debug=no --with-cocoa CXXFLAGS="-stdlib=libc++ -std=c++11" OBJCXXFLAGS="-stdlib=libc++ -std=c++11" CPPFLAGS="-stdlib=libc++" LDFLAGS="-stdlib=libc++" CXX=clang++ CXXCPP="clang++ -E" CC=clang CPP="clang -E" --enable-shared --enable-unicode --enable-threads --without-subdirs
$ make

then do some patches and bootstrap CB by CB. The binary file is located at
https://fedorapeople.org/~easior/CodeBlocks-Mac-16.01-r1.tar.bz2.
I found that some bugs are fixed, e.g. changing font size in CB Editor does not make CB crash. However, my binary file is full of bugs. For examples:
* mouse scrolling in CB Editor with some source codes will make CB crashed;
* Compiler plugin does not work well because the build target of project to build is not displayed on compiler toolbar.

The attachment is the patch which have been merged together.