textmate2: error: no matching function for call to 'begin'

[ryandesign (Ryan Carsten Schmidt)]

PlugIns/dialog/Commands/menu.mm:66:29: error: no matching function for call to 'begin'
        for(NSDictionary* menuItem : menuItems)
                                   ^

OS X 10.8.2, Xcode 4.5.2, Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)

[neverpanic (Clemens Lang)]

I've seen this before and also talked to upstream about this, but neither of us could find out why this happens. The required template definitions should be available at this point and the statement here should work. This might actually be a bug in clang.

Unfortunately this issue is not easily reproducible. If you re-try the build it might just go away.

[ryandesign (Ryan Carsten Schmidt)]

The issue is quite easy for me to reproduce; it happens every time, using the above version of clang. If this is a bug in this version of clang, please blacklist it. I think you'll also need to fix the port so that it is UsingTheRightCompiler (currently it seems to always use clang).

[neverpanic (Clemens Lang)]

The port is actually using the right compiler, unless you give it a compiler that can not be used to compile the project. Only a few very recent versions of clang will work – if you choose an incompatible version (e.g. llvm-gcc-4.2), it will fall back to Xcode's compiler or /opt/local/bin/clang, if that exists.

So the port should instead blacklist all gcc and llvm-gcc compilers; however, since those aren't the default on any supported platform, this seemed unnecessary to me.

[neverpanic (Clemens Lang)]

Is there any reason why you're not using a newer Xcode and newer command line tools? I could blacklist this version of clang and fall back to a clang compiler from macports that might, or might not, work fine, but I don't see the point in forcing users to compile a full blown clang rather than erroring out and telling them to upgrade Xcode.

[ryandesign (Ryan Carsten Schmidt)]

It does not appear to be using using the right compiler; I ran sudo port install textmate2 compiler.blacklist=clang and MacPorts then claimed that it was building with llvm-gcc-4.2, but it still built with clang. clang appears to be hardcoded in ${worksrcpath}/build/build.ninja.

This is a secondary machine, with various older OSes and Xcodes, specifically to find problems like this (on which I needed a text editor and wanted to use textmate2; I ended up downloading a binary from their web site instead). If a particular compiler will not work, you should blacklist it. It's one line to include the portgroup and one line to list the compilers you want to blacklist. This is much easier than trying to figure out other criteria for erroring out. Specifically, checking the Xcode version is not a solution, since Xcode can be updated independently of the command line tools, and it's the version of the compiler in the command line tools that matters here. Also, since we have binaries, the burden for installing a compiler via MacPorts is less than it used to be.

[neverpanic (Clemens Lang)]

It only attempts to use llvm-gcc-4.2, because you manually blacklist clang, which causes MacPorts to use llvm-gcc-4.2. LLVM GCC, however, can not be used to build textmate2, and its build system tries to be smart by looking for a different compiler that might work. I don't see a reason to stop it from doing so, though, because the Portfile currently does not blacklist clang and all supported platforms use clang as their default compiler.

We're not in a habit of blacklisting compilers that aren't being used anyway – we're not blacklisting gcc-3 on most ports, although it is in the fallback list on some systems and it will probably not compile most software in macports. This brings me back to topic: I can't test with the compiler you're trying to use, so feel free to commit a patch that will blacklist it (and then ensure a proper fallback is chosen, probably by also blacklisting llvm-gcc-4.2 and every other compiler that comes in the fallback list before a suitable clang, or just modify the fallback list to contain the host clang and a recent enough macports clang).

The build.ninja file is only created after running configure – it's not actually hardcoded, but it uses the value of $CC that it found suitable for buildig.

[cooljeanius (Eric Gallager)]

Cc Me!

[neverpanic (Clemens Lang)]

I haven't been able to reproduce this with the most recent versions in a while; I'm assume it has somehow been fixed. Please re-open if that's not the case.