A separate PortIndex for libc++ on older systems

[Ryan Schmidt]

On Jul 31, 2016, at 3:25 AM, devans at macports.org wrote:

> Revision
> 150854
> Author
> devans at macports.org
> Date
> 2016-07-31 01:25:57 -0700 (Sun, 31 Jul 2016)
> Log Message
> 
> gnome-maps: update to version 3.20.2, 3.18.3 for systems that don't support libc++, now uses maps from MapBox.
> Modified Paths
> 
> 	• trunk/dports/gnome/gnome-maps/Portfile

>  platform darwin {
> 
>      if {${configure.cxx_stdlib} eq "libstdc++"} {
> 
> -        version     3.18.2
> -        revision    1
> -        checksums   rmd160  aecfc78e6299cea8328a8803037141ee15f13fc2 \
> -                    sha256  693ff1559252eabe5d8c9c7354333b5aa1996e870936456d15706a0e0bac9278
> 
> +        version     3.18.3
> +        set branch  [join [lrange [split ${version} .] 0 1] .]
> +        master_sites gnome:sources/${name}/${branch}/
> +        checksums   rmd160  48567c80b517e8982a57b3e3e9ed6b8d126dd31e \
> +                    sha256  b164eda021a88cc7ec6773fd48428d102334b98cc196d69fa0186258b9c8b6ed
> 


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++/.

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