On Jul 31, 2016, at 3:25 AM, [email protected] wrote:

> Revision
> 150854
> Author
> [email protected]
> 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?

_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to