[MacPorts] #53122: gpgme : upgrade to 1.8.0 and +qt5 variant

[MacPorts]

#53122: gpgme : upgrade to 1.8.0 and +qt5 variant
---------------------+-------------------------------
  Reporter:  RJVB    |      Owner:
      Type:  update  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:  haspatch upstream
      Port:  gpgme   |
---------------------+-------------------------------

Comment (by dbevans):

 Replying to [comment:7 RJVB]:
 > OK, I'll see how easy it is to build just the QGpgME component;
 hopefully it's just a matter of setting `languages=qt`. I didn't want to
 say it, but yeah, it'll allow us to avoid multiple-captains-on-a-ship
 disagreements ;)
 > Either way, having a gpgme-qt5 port will allow dependents to use a
 regular depspec and not the active_variants hack.

 You've changed the proposal a bit.  We agreed on QGpgME (using qt5 and
 depending on gpgme) as a separate port.  If you want gpgme-qt5 it needs to
 be a subport of gpgme to avoid confusion.

 >
 > If others have tested the easy solution of setting _DARWIN_C_SOURCE to a
 suitable value that that will indeed be the more elegant approach. Check
 the patchfile though, there are 1 or 2 locations where I had to include a
 headerfile (strings.h) for `strcasecmp`, without having to provide an
 explicit prototype. Maybe that header will be included automagically when
 _DARWIN_C_SOURCE is set, but I don't think that that would be a proper
 fix.

 Manually setting _DARWIN_C_SOURCE bothers me a bit but is what upstream
 insists on using saying "works for me" (but only testing on darwin15).
 I'm thinking that including <cstring> instead of <strings.h> may be
 another alternative.  Will check this out after getting a cup of coffee
 under my belt.

--
Ticket URL: <https://trac.macports.org/ticket/53122#comment:9>
MacPorts <https://www.macports.org/>
Ports system for macOS