A separate PortIndex for libc++ on older systems

Mojca Miklavec mojca at macports.org
Thu Aug 11 06:00:12 PDT 2016

On 10 August 2016 at 10:37, 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?
> We also still need to decide how to differentiate the URLs for libc++ packages from the URLs of the existing libstdc++ packages. One suggestion was to add cxx_stdlib as a variable in archive_sites.conf, and upload the libc++ archives with the same names as the libstdc++ archives but in a new subdirectory, e.g. https://packages.macports.org/libc++/.

Some time back I opened a ticket at
During the MacPorts meeting the suggestion was to start using a
different path/prefix, to add an additional variable to the database
(and certainly not to mix this with changes of the compression

We could brainstorm (or at least summarize the discussion happinging
on the mailing list) in that ticket.

> Once we decide that, then do we adopt the same strategy for naming and placing the PortIndex files?

(I admit that I wasn't even aware that this could also be a problem
for PortIndex.)


More information about the macports-dev mailing list