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

[Umesh Singla]

On Sat, Sep 2, 2017 at 9:55 PM, Rainer Müller <raimue at macports.org> wrote:

> On 09/02/2017 03:18 PM, Umesh Singla wrote:
> > On Thu, Jun 15, 2017 at 12:05 AM, Mojca Miklavec <mojca at macports.org
> > <mailto:mojca at macports.org>> wrote:
> >
> >     On 14 June 2017 at 05:47, Umesh Singla wrote:
> >     >
> >     > Okay, since there's already a OS comparison made, which I think
> can be
> >     > directly used here. But to clarify, just the OS check? a check on
> x86_64/ppc
> >     > changes is also needed.
> >
> >     And potentially cxx_stdlib?
> >
> >
> > How can such a check be made possible? All we have at present is here,
> [0]. It
> > doesn't compare stored values and current platform values. Are you
> suggesting a
> > manual check while migration?
>
> I do not think we need any special check at migration, as a rebuild will
> always
> use the current setting in macports.conf. However, after editing the
> default
> cxx_stdlib in macports.conf all affected ports need to be rebuild and
> linked
> with the new default to avoid problems later when installing new ports.
>

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.

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.

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.


> 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/c4386f8c5be01
> e3f8eeba9e351373df860d9d8ab
>
> 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++?

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
> * 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.
> * I did not know/think of libstdc++ vs. macports-libstdc++
> * archivefetch does not yet respect cxx_stdlib in any way
>
> 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.


I obviously can't suggest anything right now but once I wrap up, I'll try
looking more.

- Umesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170902/2f50b99f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: macports.conf
Type: application/octet-stream
Size: 8682 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170902/2f50b99f/attachment-0001.obj>