[MacPorts] #50288: UPDATE: gpsd-3.16

[MacPorts]

#50288: UPDATE: gpsd-3.16
---------------------+--------------------------------
  Reporter:  fw@…    |      Owner:  macports-tickets@…
      Type:  update  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:  2.3.4
Resolution:          |   Keywords:
      Port:  gpsd    |
---------------------+--------------------------------

Comment (by fw@…):

 Here are the files for the 3.16 port.  I supplied both a diff of the
 Portfile against the previous published version, and the complete new
 Portfile, which is more readable (and smaller).  The patch files are
 presented as is, rather than readability-challenged diffs of diffs, and I
 also included a complete tarball of all the files with correct timestamps
 (though the repository doesn't seem to be set up to preserve timestamps).

 Changes from a file perspective:

 The two pc.in patchfiles are obsoleted by upstream fixes, and have been
 removed.

 The two remaining code patchfiles have been updated to match the updated
 sources, but are functionally unchanged (other than adding a comment line
 to the rtcm2 patch to clarify why the order matters).

 The SConstruct patchfile has been updated both because of substantial
 upstream changes to SConstruct since 3.14, and to add a couple of tweaks.

 The Portfile has changed substantially.

 Changes from a functional perspective:

 The universal variant has been disabled, since it didn't work (and would
 probably require significant work on the SConstruct script to implement).

 A new "xgps" variant has been added to determine whether the xgps and
 xgpsspeed X11 programs are included.  This is because they both require
 gobject and gtk, expanding recursively to over 150 (previously
 unexpressed) dependencies that aren't otherwise needed.  This is plumbed
 via a new SConstruct option.

 There are now three Qt-related variants - qt4, qt5, and qt.  The first two
 build against the specified Qt version, and the last is equivalent to
 whichever qtN variant is appropriate for the OS version.  This is qt4 for
 OSX < 10.8 and qt5 for OSX >= 10.8, corresponding (mostly) to the Qt5
 supported OS list.  Qt5 doesn't consider 10.11 to be a supported OS, but
 this is presumably temporary, and isn't reflected in the selection.  This
 is similar to what was suggested in #47739, though with a more aggressive
 move to Qt5.  Since the only Qt module used here is QtNetwork, and since
 none of the items listed as incompatible changes in QtNetwork appears to
 be used, it's reasonable to expect that the Qt5 substitution will work
 without any code changes.  However, the name change from QtNetwork to
 Qt5Network required adding a new option to SConstruct.

 There's a workaround for #50347 in the Qt4 setup.

 The variants now correctly control the build options and the dependencies,
 which wasn't entirely the case previously.

 The "LIBPATH='.'" arguments in the SConstruct script, which only served to
 break linking against libdbus-1, have been patched out.

 The test phase is now implemented, running all the provided regression
 tests (with a hack to keep them from being ridiculously slow - see the
 comment).

 Because 3.16 changes all the Python shebang lines to refer to "python2",
 this now explicitly depends on python2_select, and includes both a note to
 suggest using it if "python2" isn't found in the command path, and a
 similar fatal error at the start of the test phase (since the tests
 require "python2").

 The bad permissions on gpsprof (in the 3.16 release tarball) are
 corrected.

 The long description has been expanded and cosmetically cleaned up.

 Testing:

 Build/installs have been tested for no variants, maximal variants, and the
 non-default Qt variant, as well as running the regression tests.  This was
 done on a Mac Pro running 10.9.5, a PowerBook running 10.5.8, and x86_64
 VMs running all OS versions from 10.5 through 10.11.  The Qt5 builds
 failed on 10.5 and 10.6, due to the Qt5 build itself (intentionally)
 failing, but everything else worked.  Note that Qt wasn't tested beyond
 testing the builds, since there aren't any Qt tests included.

-- 
Ticket URL: <https://trac.macports.org/ticket/50288#comment:2>
MacPorts <https://www.macports.org/>
Ports system for OS X