A separate PortIndex for libc++ on older systems

[David Evans]

On 8/10/16 1:37 AM, Ryan Schmidt wrote:
> 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?
> 

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