Switching cxx_stdlib for C++11 on legacy macOS (was: Re: [GSoC] migration)

[Ryan Schmidt]

On Sep 2, 2017, at 11:25, Rainer Müller wrote:

> The following goes beyond your GSoC project, but I think it fits into this
> discussion. Back in May, I published an experiment on my GitHub repo that I had
> lying around. This adds functionality to stores the cxx_stdlib option in
> registry, such that 'port outdated' will consider ports as outdated if the
> registry entry does not match the cxx_stdlib option in macports.conf.

Thanks Rainer, I didn't remember this.


> This was originally written to support switching the cxx_stdlib from libstdc++
> to libc++ on old releases of OS X in order to support C++11. However, I
> personally lost interest to support legacy systems any longer and do not run any
> of them any more.
> 
> https://github.com/raimue/macports-base/commit/c4386f8c5be01e3f8eeba9e351373df860d9d8ab
> 
> WARNING: Do not install this commit/branch over your regular prefix as
> it will upgrade the SQLite registry.db and make it incompatible with
> MacPorts 2.4.x or master!
> 
> I am not sure how useful this experiment is yet, because this approach
> still has a number of problems and shortcomings:
> 
> * show stopper: cxx_stdlib is stored for all ports, not only those
>  actually linking against the C++ stdlib

I don't consider this a show stopper; I think it's fine to store cxx_stdlib for all ports, even non-C++ ports. I consider cxx_stdlib basically part of the platform/version, and we store that for all ports, even those that don't change how they build on different platforms/versions.


> * cxx_stdlib cannot be changed separately for a single port
>  This might be necessary for some ports that want to link against
>  system frameworks and do not link against anything else. Such a port
>  is now always be considered outdated.

Yeah I would want to fix this. There are already several ports that do this and there will be more.


> * I did not know/think of libstdc++ vs. macports-libstdc++

I also don't know how to think about that.


> * archivefetch does not yet respect cxx_stdlib in any way

Yeah that would need adjustment, based on how we decide to differentiate libc++ archives from libstdc++ archives.



> For some of these problems, I don't know how they should be solved,
> especially the first show stopper. But maybe this helps to get the ball
> rolling a bit more.