Switching cxx_stdlib for C++11 on legacy macOS

[Rainer Müller]

On 2017-09-02 19:38, Umesh Singla wrote:
> As stupid as it seems but I don't see any cxx_stdlib option in my
> macports.conf (see attached). Option $macports::cxx_stdlib seems to be
> configured while mportinit (which means runtime, I guess) depending on
> $os_platform and $os_major. So, it should suffice not to check for it.

Not all of our bootstrap_options are listed in the default config file,
but they would be recognized if you added them.

https://github.com/macports/macports-base/blob/v2.4.1/src/macports1.0/macports.tcl#L48-L59

> The fact that surprises me is that even $mapcorts::build_arch is left to
> configure on runtime depending on again, only $os_platform, $os_arch and
> $os_major and they are NOT stored anywhere (macports.conf or
> macports::autoconf namespace). All these options come from $tcl_platform
> which will change as soon as the platform changes. So, this says that
> only the check like this:
> 
> {($os_platform ne $macports::autoconf::os_platform) || ($os_major !=
> $macports::autoconf::os_major)}
> 
> should be enough for suggesting to migrate. I'm not able to find any way
> to include the check on, as quoted in migration guide, "architecture
> migrations (e.g., from PowerPC to Intel)" which could be helpful.

Isn't his exactly what we are already using to print the link to the
Migration wiki page?

> Also, if it is, I can simply add migrate action to run `-f selfupdate`
> because it seems that selfupdate.tcl handles downloading and installing
> a appropriate macports-base release. Any help is appreciated.

selfupdate should detect the platform change as an indicator to
reinstall instead of requiring a forced rebuild. In that case, it should
also skip syncing the ports tree.

>     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.
> 
>     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
>     <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!
> 
> 
> Sure, this is a helpful point to keep in mind. Though, any reasons to
> not switch to libc++?

As I understand it, to support C++11 the only way is to switch to
libc++. This would be quite easy for new installations by simply
switching the default of cxx_stdlib. However, as it is an incompatible
change, this would break all existing installations, therefore a way to
convert these existing installations should be implemented first.

The other option to switch would be to just change the default of
cxx_stdlib with the next 2.x release, wipe all existing binary packages
and ask all existing users on legacy systems to uninstall, then
reinstall all their ports. Less work for developers, much frustration
for users.

Rainer