port modifications required by making qt4-mac co-installable with Qt5

[RJVB (René Bertin)]

As a companion to ticket #44193, here's an initial list of ports I had to change in order to get them to build with a qt4-mac port that no longer installed in the "traditional", "exclusive" locations. These changes are mostly replacing hardcoded locations with variables provided by the PortGroup.

I suggest we use the attachment description entry widget to comment on specifics.

That said, I'll start off by pointing out that port:goldendict installs the app bundle into /Applications/MacPorts instead of into /Applications/MacPorts/Qt4 (and also manages to ignore global settings set through qtconfig but that's an independent issue).

[RJVB (René Bertin)]

This diff makes qca compatible with concurrent qt4-mac, upgrades it to the current version (which requires making qca-ossl a subport) and also introduces a qca-qt5 subport

[RJVB (René Bertin)]

Sorry about the upload glitch.

The current QCA version includes all "components" that previously were separate sources and ports. As a result, not only qca-ossl has been made a subport, but also qca-cyrus-sasl, qca-gnupg and qca-tls.

One port to rule them all ... and in security bind them :)

[RJVB (René Bertin)]

patch to allow building against Qt 5.5.0

[RJVB (René Bertin)]

required entries for attica's ${filespath} ​https://github.com/RJVB/macstrop/tree/master/kde/attica/files/qt5

NB: test-building Qt4 dependents should be done not only against a concurrent Qt4 port, but also with a Qt5 port installed and active.

[michaelld (Michael Dickens)]

Replying to rjvbertin@…:

NB: test-building Qt4 dependents should be done not only against a concurrent Qt4 port, but also with a Qt5 port installed and active.

Hadn't gotten there yet, but this is a very good idea. Of course, I'm using 10.11.1 beta, and qt5-mac does not build on it for testing purposes. So, I can't really test this just yet; some day!

[RJVB (René Bertin)]

Hadn't gotten there yet, but this is a very good idea. Of course, I'm using 10.11.1 beta, and qt5-mac does not build on it for testing purposes.

I cannot even guarantee that qt5-kde builds there, but it does have the patches that should be enough.

[michaelld (Michael Dickens)]

Patches == not enough, at least for my system. Here's the error:

:info:build clang: error: no such file or directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib/libz.dylib'
[snip]
:info:build ninja: build stopped: subcommand failed.
:info:build make[4]: *** [invoke_ninja] Error 1
:info:build make[4]: Leaving directory `/opt/local/var/macports/build/_Users_Shared_source_MacPorts_trunk_dports_aqua_qt5-mac/qt5-mac/work/qt-everywhere-opensource-src-5.4.2/qtwebengine/src/core'

which is odd because we specify --system-zlib and port:zlib is a dependency and installed; and LIBRARY_PATH=/opt/local/lib, which is where libz.dylib is installed. After a bit of searching, I came up with ​http://bugs.python.org/issue25136 , because libz.tbd does exist in the above directory & apparently is a placeholder that we can use for linking to an actual libz.dylib (somewhere, somehow). But, more important is that Qt5 isn't even trying to find /opt/local/lib/libz.dylib -- a quick search right after doing extra verifies that the SDK directory is what is used by qtwebengine. Bad Qt5!

[RJVB (René Bertin)]

That sounds like the kind of mix-up I ran into with Qt5 build system and using pkgconfig on OS X, which appears to be something they didn't test too exhaustively. Also not the 1st issue I know of with QWE's ninja-based build system.

.tbd ... to be done indeed ...

It *is* strange that Digia didn't test such a brand new release on an OS that was about to be released just after 5.5.0 . Meanwhile, this speaks for my approach of putting QtWebEngine in its own subport. Saves a lot of time and space building Qt5, too.

[RJVB (René Bertin)]

Oh, that error is with Qt 5.4.2 (which I didn't patch for 10.11). With Qt 5.5.0, I only see a reference to libz in qtwebengine/src/3rdparty/chromium/chrome/installer/mac/third_party/bsdiff/goobsdiff.gyp: '$(SDKROOT)/usr/lib/libz.dylib'. That looks like it might spell trouble, but I don't see how it could be related to the error above.

To install a Qt5 port without QtWebEngine, just remove ${worksrcpath}/qtwebengine (/opt/local/var/macports/build/_Users_Shared_source_MacPorts_trunk_dports_aqua_qt5-mac/qt5-mac/work/qt-everywhere-opensource-src-5.4.2/qtwebengine in your case I guess) AFTER port patch, and remove the qtwebengine module entry from qt.pro, BEFORE port configure (or simply port install). If you just move the qtwebengine somewhere else, you can go there after installing Qt5 and configure/build it like any qmake project. That just might lead to different results.

[RJVB (René Bertin)]

It's been a while, I've finally gotten around to building the 1st true Qt5 dependent port that also depends on Qca (the KF5 Okteta version). I've had to make port:qca-qt5 use the version provided by KDE; updated patch attached.

As far as I can tell, the only difference is in the cmake modules (except for what appear to be a few minor fixes).

[RJVB (René Bertin)]

FWIW:

> port dependents qca-qt5
kf5-konversation-devel depends on qca-qt5
kf5-okteta depends on qca-qt5
kf5-okular-devel depends on qca-qt5
qca-qt5-cyrus-sasl depends on qca-qt5
qca-qt5-gnupg depends on qca-qt5
qca-qt5-ossl depends on qca-qt5

[mkae (Marko Käning)]

Is this ticket related to #52689?

[mkae (Marko Käning)]

This should be superseded by #49924!

[RJVB (René Bertin)]

Replying to mkae:

This should be superseded by #49924!

Only attica.diff attachment, not the others.

[mkae (Marko Käning)]

Which of the attached patches are actually still to be applied?

Can you update those which need updating?

[RJVB (René Bertin)]

aaargh, I see I haven't followed port:qca at all, and in the time since I submitted even the newest qca.diff so much has changed in the stock port:qca that it's become just about impossible to merge "my" and "their" ports.

This really makes me wonder why I even bother submitting patches and ports; my efforts are mostly being ignored. I see no other solution than to split off my qca-qt5 subports - or else I take over maintainership (qca no longer has one) and we just push my version. That would mean giving up on building the library as a framework but so be it. I'll start work on the split-off but finalise it only after a decision has been made.

[RJVB (René Bertin)]

This diff makes qca compatible with concurrent qt4-mac, upgrades it to the current version (which requires making qca-ossl a subport) and also introduces a qca-qt5 subport

[RJVB (René Bertin)]

not so much an update to concurrent qt4-mac but a fix for the depends_lib reset caused by the Python PortGroup

[mkae (Marko Käning)]

attica.diff does not provide a qt5 variant, right? (The text above is misleading.)

[mkae (Marko Käning)]

Replying to RJVB:

... or else I take over maintainership (qca no longer has one) and we just push my version. That would mean giving up on building the library as a framework but so be it. I'll start work on the split-off but finalise it only after a decision has been made.

Well, if no one objects to this approach...

I hope this gets a discussion going, as the CC list contains quite a few interested users.

[RJVB (René Bertin)]

ditto, a fix for the depends_lib reset caused by the Python PortGroup. Also introduces working support for DBus and +qtwebkit and +qtwebengine subport to allow using PyQt5 without installing those huge obsolete resp. newish Qt component

[RJVB (René Bertin)]

port:attica : make it build with Qt5 installed and active

[RJVB (René Bertin)]

Replying to mkae:

attica.diff does not provide a qt5 variant, right? (The text above is misleading.)

Sorry, yes, I removed the qt5 *subport* which is now obsolete.

Do the Germans have this notion of "silence/absence of critique signals acceptation" ? ;)

[mkae (Marko Käning)]

Replying to RJVB:

Do the Germans have this notion of "silence/absence of critique signals acceptation" ? ;)

Well, I think it's up to you to judge that, but perhaps it's only my personal issue and not a German one... ;)

[RJVB (René Bertin)]

Replying to mkae:

Do the Germans have this notion of "silence/absence of critique signals acceptation" ? ;)

Well, I think it's up to you to judge that, but perhaps it's only my personal issue and not a German one... ;)

Well, it *is* a Dutch proverb, and it's something I indeed do believe in :)

[mkae (Marko Käning)]

Replying to RJVB:

Well, it *is* a Dutch proverb, and it's something I indeed do believe in :)

I hope it's a likeable thing. :)

[RJVB (René Bertin)]

I guess that depends whether you have a habit of keeping your mouth shut while in fact you should be speaking up ;)

[mkae (Marko Käning)]

Parts of this, René, should now be committed. Can you cross-check what we're still missing in MacPorts' central repo? (Surely the python modules. Not sure about the attica patch... No time to check now.)

[RJVB (René Bertin)]

attica has had recent attention in a different ticket. I trust Nicos has done what it takes to allow it to build.

The py-qt patches are relatively recent and c/should indeed be tested independently and committed.

Everything qca-related ought to be covered by the qca pull request; the corresponding attachments can be deleted.

[mkae (Marko Käning)]

In 6982d65/macports-ports:

py-pyqt4: fix for the depends_lib reset caused by the Python PortGroup

See also: #49109

[mkae (Marko Käning)]

I already mended py-pyqt5 in #51620, so I guess this ticket can now be considered closed.

[mkae (Marko Käning)]

In d0ab4387/macports-ports:

py-pyqt4: fix for the depends_lib reset caused by the Python PortGroup

See also: #49109