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

[Ryan Schmidt]

On Sep 6, 2014, at 5:51 AM, Mojca Miklavec wrote:

> I already argued that we really need a libc++-based buildbot for 10.6-10.8.
> 
> From what I understood all we need is a fix in binary package
> signature + time and resources to set up the buildbots. Once the
> buildbots run, people can start testing and switching to libc++. Once
> we get to a satisfactory support, we can recommend everyone to switch
> and retire the libstdc++-based buildbots if needed.
> 
> Switching from libstdc++ to libc++ would be equal to switching from
> 10.x to 10.(x+1). (Nice to automate one day, but people should switch
> manually for now and reinstall everything from scratch.)

Anything where we're asking people to manually reinstall things is, IMHO, a niche situation. My guess is that a few very interested and involved people subscribe to the macports-users list, but that the vast majority of MacPorts users just use it and never communicate with the community. Those users should be given a smooth upgrade experience as well; they shouldn't have to seek out help to get the best MacPorts experience; it should just work.

Do we already record the C++ runtime in the registry with each installed port? If not, we should do that, in addition to getting it into the binary filenames. And just as we do for architectures, maybe we should have an indication for software that doesn't use any C++ runtime ("nocxx"?).

Presumably we would (or possibly already do) record in the registry the value of configure.cxx_stdlib. But it would be nice if we would also automatically check (somehow: either as part of the install, or maybe as part of rev-upgrade) that the specified C++ library is the one that actually got used. Similarly, it would be nice if we checked that the architectures we recorded are the architectures that actually got built.


> The libc++-based MacPorts works well on < 10.9 already for most
> packages.

Good to know many ports have worked, but I still suspect there are many ports you either haven't tried or haven't noticed the situations where libstdc++ is still being used even though libc++ was requested. An automated check would help with this.


> Supporting libstdc++ is getting increasingly painful with
> more and more software depending on C++11.

Agreed.