[100023] trunk/dports/devel/codeblocks/Portfile

[Anders F Björklund]

Ryan Schmidt wrote:

>> It's not so much that clang is on the blacklist, as it is that Code::Blocks 10.05
>> was only tested with wxMac and Snow Leopard and thus requiring both GCC and SDK...
>> 
>> For it to work with later releases, someone would need to port it to wxOSX/Cocoa.
>> But that won't happen until the next release, so is different from "fixing" the port.
>> 
>> Will add llvm-gcc-4.2 and MacOSX10.6.sdk for Lion, but Mountain Lion is out (for now).
> 
> The default compiler on Xcode 4.2 and later is clang. If this software does not build with clang, then write:
> 
> compiler.blacklist clang
> 
> This is how we are doing it in other ports. This helps us to be able to `grep` over all portfiles to find those that are incompatible with clang, so that we can eventually fix them, since clang is the present and the future of compilation on OS X. It seems clear that Apple wants us to consider gcc on OS X dead.

It doesn't matter, since someone still needs to put in the work to upgrade it first...
In this case it needs the MacOSX10.6.sdk to compile, which Apple doesn't provide anymore.

The port is already banned from even trying, so there is no way to install wxMac there:
"wxWidgets cannot build on 10.7 with Xcode >= 4.4, please use port wxWidgets-devel instead"

See http://trac.macports.org/ticket/35372

So to have a chance of building with latest Xcode, it needs to be ported to wxOSX first...
If someone is interested in doing that, then volunteer at http://forums.codeblocks.org/

> If this software is not incompatible with clang, then certainly don't blacklist clang; instead, allow MacPorts to choose clang as the compiler and do not alter configure.compiler.

I'll keep the current workaround for Lion. It matches the settings for the wxWidgets port.
Supposedly one could get it working with clang and wxGTK instead... Then again, why bother ?

Once the Mac OS X 10.6 SDK (i.e. Snow Leopard, Xcode < 4.4) is not supported, delete the port.
There is a binary installation of Code::Blocks, if really needed... Even uses the 10.4u.sdk.

But since it is using Carbon it also means that it only runs as 32-bits, as in: ppc/i386.

--anders