On Sep 2, 2017, at 11:25, Rainer Müller wrote: > 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.
Thanks Rainer, I didn't remember this. > 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 > > 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! > > 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 I don't consider this a show stopper; I think it's fine to store cxx_stdlib for all ports, even non-C++ ports. I consider cxx_stdlib basically part of the platform/version, and we store that for all ports, even those that don't change how they build on different platforms/versions. > * 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. Yeah I would want to fix this. There are already several ports that do this and there will be more. > * I did not know/think of libstdc++ vs. macports-libstdc++ I also don't know how to think about that. > * archivefetch does not yet respect cxx_stdlib in any way Yeah that would need adjustment, based on how we decide to differentiate libc++ archives from libstdc++ archives. > 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.
