On Sun, Sep 3, 2017 at 5:17 PM, Rainer Müller <[email protected]> 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.
