<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 2, 2017 at 9:55 PM, Rainer Müller <span dir="ltr"><<a href="mailto:raimue@macports.org" target="_blank">raimue@macports.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 09/02/2017 03:18 PM, Umesh Singla wrote:<br>
> On Thu, Jun 15, 2017 at 12:05 AM, Mojca Miklavec <<a href="mailto:mojca@macports.org" target="_blank">mojca@macports.org</a><br>
> <mailto:<a href="mailto:mojca@macports.org" target="_blank">mojca@macports.org</a>>> wrote:<br>
><br>
>     On 14 June 2017 at 05:47, Umesh Singla wrote:<br>
>     ><br>
>     > Okay, since there's already a OS comparison made, which I think can be<br>
>     > directly used here. But to clarify, just the OS check? a check on x86_64/ppc<br>
>     > changes is also needed.<br>
><br>
>     And potentially cxx_stdlib?<br>
><br>
><br>
> How can such a check be made possible? All we have at present is here, [0]. It<br>
> doesn't compare stored values and current platform values. Are you suggesting a<br>
> manual check while migration?<br>
<br>
I do not think we need any special check at migration, as a rebuild will always<br>
use the current setting in macports.conf. However, after editing the default<br>
cxx_stdlib in macports.conf all affected ports need to be rebuild and linked<br>
with the new default to avoid problems later when installing new ports.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>{($os_platform ne $macports::autoconf::os_<wbr>platform) || ($os_major != $macports::autoconf::os_major)<wbr>}</div><div><br></div><div>should be enough for suggesting to migrate. I'm not able to find any way to include the check on, as quoted in migration guid<font face="arial, helvetica, sans-serif">e, "<span style="color:rgb(0,0,0);font-size:13px">architecture migrations (e.g., from PowerPC to Intel)</span>" which could be helpful.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">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.</font></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The following goes beyond your GSoC project, but I think it fits into this<br>
discussion. Back in May, I published an experiment on my GitHub repo that I had<br>
lying around. This adds functionality to stores the cxx_stdlib option in<br>
registry, such that 'port outdated' will consider ports as outdated if the<br>
registry entry does not match the cxx_stdlib option in macports.conf.<br>
<br>
This was originally written to support switching the cxx_stdlib from libstdc++<br>
to libc++ on old releases of OS X in order to support C++11. However, I<br>
personally lost interest to support legacy systems any longer and do not run any<br>
of them any more.<br>
<br>
<a href="https://github.com/raimue/macports-base/commit/c4386f8c5be01e3f8eeba9e351373df860d9d8ab" rel="noreferrer" target="_blank">https://github.com/raimue/macp<wbr>orts-base/commit/c4386f8c5be01<wbr>e3f8eeba9e351373df860d9d8ab</a><br>
<br>
WARNING: Do not install this commit/branch over your regular prefix as<br>
it will upgrade the SQLite registry.db and make it incompatible with<br>
MacPorts 2.4.x or master!</blockquote><div><br></div><div>Sure, this is a helpful point to keep in mind. Though, any reasons to not switch to libc++?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I am not sure how useful this experiment is yet, because this approach<br>
still has a number of problems and shortcomings:<br>
<br>
* show stopper: cxx_stdlib is stored for all ports, not only those<br>
  actually linking against the C++ stdlib<br>
* cxx_stdlib cannot be changed separately for a single port<br>
  This might be necessary for some ports that want to link against<br>
  system frameworks and do not link against anything else. Such a port<br>
  is now always be considered outdated.<br>
* I did not know/think of libstdc++ vs. macports-libstdc++<br>
* archivefetch does not yet respect cxx_stdlib in any way<br>
<br>
For some of these problems, I don't know how they should be solved,<br>
especially the first show stopper. But maybe this helps to get the ball<br>
rolling a bit more.</blockquote><div><br></div><div>I obviously can't suggest anything right now but once I wrap up, I'll try looking more. </div><div><br></div><div>- Umesh</div></div></div></div>