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

[Mojca Miklavec]

On Sun, Sep 7, 2014 at 12:52 AM, Ryan Schmidt wrote:
> 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.

I never suggested doing dramatic changes that would *require* users to
do a manual upgrade. But at least to those users that start
complaining about mkvtoolnix crashing, we would have a satisfactory
answer: go to this wiki page and follow instructions to switch to
libc++.


Switching to libc++ only means changing a single setting in
macports.conf. (For better support this also means changing the binary
signature depending on which libc++/libstdc++ library is being used
and setting up a buildbot.)

Support for libstdc++ can stay (to the extent that port maintainers
will support it – same as with support for Tiger).

It would be weird if we forced users to switch to a different runtime.
If nothing else I bet there are users who would really want to keep
using libstdc++ for various reasons (easier to compile [own] software
manually etc.) and don't bother about C++11.

But it would be really really nice to create a mechanism that:
- remembers which ports are installed and which ones are requested
- deactivates (and possibly uninstalls) all ports
- installs all the ports again
which could be applied in both situations:
- switching to a different library or changing some other options in
macports.conf (maybe change applications_dir or frameworks_dir or so)
- upgrading the OS

But that's not *required* to improve support for libc++ on older OSes.

> 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"?).

This is something that I'm not familiar with at all. I would be very
grateful if some other developer would add the necessary code. I'm
willing to keep testing and fixing ports ...

> 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.

Most definitely there are other/more problems to be expected. If we
add a buildbot, it will be a lot easier to get more people to test.

Mojca