A separate PortIndex for libc++ on older systems

[Mojca Miklavec]

Hi,

I wrote this quite a while ago and then forgot to send it out.

In short: yes, I believe that we should start distributing a separate
PortIndex for libc++-based systems and that we should make final
decisions rather sooner than later. (Maybe time to schedule an
"online/irc meeting" to push things forward?)

We should really decide how to distribute libc++-based archives as
soon as possible (and ideally use the xz compression).

On 11 August 2016 at 22:13, David Evans wrote:
> On 8/10/16 1:37 AM, Ryan Schmidt wrote:
>>
>> Currently, there is only one PortIndex file generated on the server, and published to the rsync server, for each OS name/version/endianness combination. So for example, there is one PortIndex for Darwin 12 Intel. There is not currently a separate PortIndex for Darwin 12 Intel with libc++, so anyone with e.g. OS X 10.8 with libc++ syncing from the rsync server will see the version of this port as 3.20.2 not 3.18.3 when querying the index, for example when running port info or port outdated. If we're going to change Portfile attributes such as version that get stored in the index based on the C++ library, and I agree this is a situation that would arise more and more as newer versions of software require libc++, should we make a separate libc++ PortIndex for 10.6/10.7/10.8?
>>
> It makes sense to me that we should put pressure on
> users with older platforms to configure themselves to use libc++
> where they possibly can rather than giving them further
> excuses to stay with libstdc++ and C++98.

I would rather say that we should put pressure on *us* to distribute
binaries compiled against libc++ and to provide dmg downloads for
MacPorts that are pre-configured to use libc++. And perhaps a way to
auto-upgrade from stdlibc++ to libc++. (MacPorts has a database of
active and requested ports; I still believe that it shouldn't be too
difficult to remember the list of active / requested ports, deactivate
them all and then install the same ones from the libc++ package
archives.)

Non-existence of binary archives is an extremely strong argument to
stick with libstdc++ on < 10.9, but once the binary packages are
there, I no longer see a problem.

Since very recently the first step (building and distributing the
binary archives from new build slaves) finally became possible and
will be done once we decide about the proper strategy.

Auto-upgrades are a different issue, but it's not a critical one and
certainly not any more painful than reinstalling MacPorts after system
upgrade.

> Maybe put the onus on those who want to stay with the older systems to curate
> a separate repository(ies) altogether of ports whose versions are cherry picked to be compatible with their systems.
> You could even provide separate buildbots for these systems.

Cherry-picking old releases for C++11 software might be doable to some
extent, but requires quite some additional manpower that we are
lacking anyway. The major problem I see is all the revbumping that's
required to keep the system functional (when a dependency gets
upgraded, the port should be updated) and at some point one piece of
software will require a newer dependency etc. So only a semi-official
repository for old OSes would work. Fink uses a separate "repository"
for each OS version, but that's even more painful to maintain.

///

One potential problem that just came to my mind. There are ports that
don't require global libc++ setup, but can do just fine as long as
/usr/lib/libc++.dylid is there. That's always the case on >= 10.7 and
conditionally true on <= 10.6, based on whether or not the user
bothered to install libc++ (there's a package for that on 10.6 and
some pain involved on 10.5).

Jeremy uses the code
    if {[file exists /usr/lib/libc++.dylib]} {
        ...
    }
in cctools and I would like to use that code to make the decision of
whether or not to create an additional subport or not.

This might be slightly more tricky to cover properly because it might
depend on user setting and the current set of installed ports.

Mojca