On 8/10/16 1:37 AM, Ryan Schmidt wrote: > 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? >
OK, I just tumbled to what you're saying here. As you say, the indexed version of this port will be determined by the value of configure.cxx_stdlib on the machine that is doing the indexing and, for those that use the rsynced indexes, that machine may not be running the same C++ configuration (or even the same OS version) as the user's machine. This works for me because, as a maintainer, I use subversion to fetch Portfiles and regenerate the PortIndex myself. In that context this works fine. As you say, the world is quickly moving on. Even projects like Inkscape, which has been slow to update to C++11 and gtk3 has announced that the upcoming 0.92 release will be the last to support C++98 (libstdc++) and gtk2. Trunk development has already moved to requiring C++11 and libc++ to build. Similarly, glibmm, gtkmm3 and friends have required C++11 (libc++) to build for two stable release cycles now and are proposing requiring C++14 in the next based on the fact that that is the default standard for gcc6. So, while I have been tracking the latest releases in my C++11 respositories, I have been holding back on some of these releases for a while pondering how to handle this libstdc++/libc++ dichotomy. Personally, given time and resouces, I would rather dispense with maintaining outdated versions of GNOME ports altogether and just use the cxx11 PortGroup where applicable. 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. 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. So, before coming up with more complex indexing systems, etc, maybe we need to take a clear look at what we can really afford to support. At the very least, the newer standards should have a higher priority for support over the older. Right now I feel like it's the other way round. END OF DAVE'S (mini) RANT FOR TODAY :-) GETTING BACK TO REALITY: So, I wonder, rather than trying to design and disseminate a single PortIndex that will work for all circumstances, have you considered modifying port selfupdate to regenerate the PortIndex on the user's system after rsyncing ports rather than including it prebuilt? Speaking as one who does this on a regular basis, the additional overhead isn't much if people keep relatively up-to-date. Or would it really be a disaster if we took a hard stand on only supporting 10.9+? I see the new buildbots already label 10.8 and earlier as legacy so maybe we're half way there already. > > 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? Perhaps, but you probably also need a way to specify whether a given port is able to build with either libc++ or libstdc++ or both to guide/facilitate this process. Possibly something like supported archs. For example, as mentioned above, Inkscape will shortly be a libc++ only port and latest glibmm and friends already are while others like boost support either while yet others only support libstdc++. If doing subdirectories for packages, I would submit that the default should be libc++ as that will quickly be the dominant mode if it is not already. Reserve the special case subdirectory for the diminishing libstdc++ Does adding this structure mean that we (maintainers) need to provide older versions of ports to support libstdc++ compatibility or is it sufficient to just support the latest libc++ versions. Anyway, just a few thoughts. Dave _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
