Switching cxx_stdlib for C++11 on legacy macOS

[Umesh Singla]

On Sun, Sep 3, 2017 at 5:17 PM, Rainer Müller <raimue at macports.org> wrote:

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

Yes, it is. That's why I asked if the condition was always enough in the
first place to check for the need of migration and having a forced and
--nosync selfupdate for migration we require now to embed.

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


This makes it easy for migration. We can simply run selfupdate with f and
nosync from the migration.

>     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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170903/1e56f7c7/attachment.html>