qt4-mac lacks global pkgconfig data

[fhgwright (Fred Wright)]

In tracking down why gpsd can no longer find the qt4 QtNetwork library with pkgconfig, I think I found the problem. The qt5 Portfile has code starting at line 1300 as follows:

# put configuration files in places they will be found automatically

However, there is no equivalent in the qt4-mac Portfile. I suspect that this was an oversight related to moving the qt4 files into ${prefix}/libexec/qt4/ to allow parallel installations of qt4 and qt5 (r140960), and that older versions of qt4-mac were "naturally findable" by pkg-config.

In the case of gpsd, this doesn't result in any build errors, since its SConstruct script silently (albeit visible with -v) disables the qt option when it can't find the QtNetwork library.

[fhgwright (Fred Wright)]

In 7172ab2b575c8ca83218ceec6bd9b2f815e9db31/macports-ports:

gpsd: update to 3.17

This is a substantial rework from the last published version (3.14).
The upstream version now works almost "out of the box", except for one
last-minute bug which is fixed here by a patchfile duplicating the
upstream post-release patch.

Changes from a functional perspective (other than upstream changes):

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
cairo, py-gobject3 and gtk3, expanding recursively to 202 additional
(previously unexpressed) dependencies that aren't otherwise needed.
The fact that these were unconditionally included (but without the
dependencies) created a dilemma for the default, since defaulting to
no means omitting the previously included programs, but defaulting to
yes means adding all the dependencies for programs that may not
actually be used. The chosen compromise is to default to no but with
a note warning the user about the need for the variant.

An earlier version of this work supported choosing either Qt4 or Qt5
for Qt support. In the meantime, something changed in Qt5 causing
gpsd not to build with Qt5, so for now the qt variant is back to
Qt4-only.

There's a workaround for the long-standing pkgconfig bug in qt4-mac
(#50347).

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

The Python programs are now shebanged to the chosen Python, which for
now is fixed at 2.7.

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

The long description has been expanded and cosmetically cleaned up.

TESTED:
Built and ran on MacPro/10.9, PowerBook/10.5, and VMs for all OS
versions 10.5-10.13. Tested with no variants, single variants, and
all variants, except that +xgps doesn't currently work on PPC due to
issues with gtk3 and py-gobject3.

[fhgwright (Fred Wright)]

Was the posting of the gpsd commit message here just something automated? The gpsd update doesn't fix this bug, although it does reference it in mentioning that it has a workaround for this bug's *not* being fixed.

[ryandesign (Ryan Carsten Schmidt)]

Replying to fhgwright:

Was the posting of the gpsd commit message here just something automated?

Yes. You included this ticket's URL in the commit message, therefore the system mentioned the commit in this ticket.

[fhgwright (Fred Wright)]

This was apparently fixed at some point, without updating the ticket. The gpsd port now builds (on 10.5-10.13) with +qt and without the pkgconfig workaround.

I'd close the ticket if it would let me. :-)

[fhgwright (Fred Wright)]

I was mistaken about this being fixed. It seems that I'd added a symlink to my system as a local workaround, and forgot that it was there when calling this "fixed". It should be reopened, but I don't have permissions to do that. Whether reopening the ticket actually gets it fixed is another matter. :-)

[michaelld (Michael Dickens)]

So you're suggesting to add (roughly) the following lines in the Qt5-qtbase Portfile to qt4-mac: ​https://github.com/macports/macports-ports/blob/master/aqua/qt511/Portfile#L1847-L1856 .... hmmm ... I think that would be doable since all of the PC files start with just "Qt", while those for Qt5 start with "Qt5" ... I have no conflicts in my ports install with plenty of extra stuff around ... hmm ....

[fhgwright (Fred Wright)]

That looks like the right general idea, though I don't know about the similar stuff for CMake. In general, the idea is to make pkg-config for Qt4 components behave the way it does on other platforms, rather than requiring ports that use Qt4 to have either MacPorts-specific hacks in the upstream code, or hacks in the Portfiles (which doesn't work for "bare" builds outside MacPorts).

[michaelld (Michael Dickens)]

I'm building qt4-mac with a change as I write. Even on my fancy new-ish 8-core MBP 15", it does still take a bit to build.

Do you know if SConstruct takes environment variables as hints? Qt (4 or 5) finders often use "QTDIR" and/or "QMAKE" ... not quite the same as having PC files in a default location where PC will find them, I know .. but often very helpful to be able to set one of these variables to point to the correct Qt install.

[michaelld (Michael Dickens)]

​https://github.com/macports/macports-ports/pull/6005

[michaelld (Michael Dickens)]

I'll merge once the CI passes. I'll check when I get into work tomorrow.

[michaelld (Michael Dickens)]

Closed by ​https://github.com/macports/macports-ports/commit/a5ed8499baebc893e06cb2821d28ce43d944dabf

[michaelld (Michael Dickens)]

I'd still encourage the use of "QTDIR" and/or "QMAKE" ... but this change makes a lot of sense & will help some ports find Qt4 where they couldn't before!

[fhgwright (Fred Wright)]

Well, the purpose of pkg-config is to allow software to get all the information about using a package based on just its name. Requiring the software to supply information about where to find the .pc file partially defeats the purpose. Granted, this requires that the package name be globally unique, and it might have been better to use some sort of domain naming system, but having to use QTDIR or QTMAKE just seems like a kludge.

In any case, it's working now. This time for sure. :-)