kdevelop 4.7 and beyond (was: clang++-mp-3.4 doesn't find initializer_list on OS X 10.6)

[Lawrence Velázquez]

(Moving to macports-dev, which is long overdue. Prior history at http://thread.gmane.org/gmane.os.apple.macports.user/35812)


On Sep 8, 2014, at 4:24 AM, Mojca Miklavec <mojca at macports.org> wrote:

> On Sun, Sep 7, 2014 at 8:36 PM, Lawrence Velázquez wrote:
>> 
>> All this talk about keeping track of C++ runtimes and switching to libc++ is dangerous because it proposes a huge amount of work that deftly dances around the actual problem.
> 
> It's not a huge amount of work. It already works. The question is
> about providing a buildbot with binaries.

Which would require adding code to track the C++ runtime; doubling the number of archives to build, store, and distribute for each C++ port; etc. It's not just a simple matter of flipping some bits in macports.conf and calling it a day.

Not that it's a bad idea. I'm just saying that it's a huge workaround.

> What do you mean with "dancing around the actual problem"? The problem
> is that the default libstdc++ on < 10.9 doesn't have support for
> C++11.

That's true, but it's a red herring. If our libstdc++ wasn't broken, ports would not have to avoid it.

Our actual problem is that none of the g++ compilers we distribute are viable because they don't use the system's C++ runtime. If we successfully move the whole operation over to libc++, they'd still be broken.

Theoretically speaking, if our libstdc++ used the system libc++abi, we wouldn't be in this mess. Ports could use our C++11-supporting-libstdc++ without a problem, just like they can use the system libstdc++. (Theoretically.)

> (But yes, the use of GPLv3 has something to do with the issue. The
> version of libstdc++ that supports C++11 no longer provides a suitable
> licence for Apple.)

I'm aware. That's also why the contributor most qualified to fix the problem I outlined cannot do so.

vq