co-installable qt4-mac and qt5-mac step1 : qt4-mac +concurrent

[Craig Treleaven]

At 10:56 AM +0100 12/20/14, René J.V. Bertin wrote:
>On Saturday December 20 2014 17:44:30 Ian Wadham wrote:
>
>Morning Ian!
>
>>It is a great start !!!  Thanks very much René!
>
>You are welcome (and I and the rest of us...) Someone had to do this...
>
>I was hoping a few other MacPorts/KDE-Mac users 
>could try this, esp. those doing work on Qt5/KF5 
>...
>One test that could indicate whether indeed this 
>allows concurrency is to install 
>qt4-mac+concurrent (*not* qt4-mac-transitional) 
>and the current, unmodified qt5-mac .
>I think that ought to work.
>
>>    a) Traditionally you can install new or 
>>development versions of Qt "somewhere else"
>>         and point to your test or development 
>>version via environment variable $QTDIR.
>>         Does this presuppose a fixed hierarchy 
>>of directories and names under $QTDIR?
>>         If so, changing that hierarchy may cause problems.
>
>I think that nowadays the QTDIR "trick" is 
>mostly to use a test version in a different tree 
>with applications that were already linked to 
>your usual version. If so, that means that QTDIR 
>must point to a complete directory and as long 
>as that's the case you should be fine.
>QTDIR is not (no longer?) required for running.
>
>>   b) Shifting Qt libraries from ${prefix}/lib 
>>to ${prefix}/libexec/${qt_name}/lib might be
>>        a "no-op".  In the lib subdir 
>>(/opt/local/lib on my system), Qt libraries are 
>>installed
>>        as links.  For example, libQtCore.dylib, 
>>libQtCore.4.dylib, libQtCore.4.8.dylib and
>>        libQtCore.4.8.6.dylib all point to 
>>/opt/local/Library/Frameworks/QtCore.framework/QtCore,
>>        which in turn points to 
>>Versions/4/QtCore and THAT is actually a file 
>>described as
>>        Versions/4/QtCore: Mach-O 64-bit x86_64 
>>dynamically linked shared library.
>>
>>Maybe I am missing something.
>
>Yes, you are :) Those frameworks have been moved too.
>qt4-mac and qt5-mac use a sneaky trick to 
>provide a combined framework and traditional 
>build, based on the fact that an OS X framework 
>is nothing but a shared library (without the 
>usual extension) combined with all associated 
>stuff bundled in a specific way. You can get 
>very close by using 
>--prefix=/Library/Frameworks/foo/Versions/${MAJOR_VERSION} 
>and then setting up a couple of symlinks to 
>disclose certain things a bit more directly.
>So symlinking framework binaries as you saw 
>makes the link editor can find them ... it 
>already knows how to handle them.
>
>All that to say that no, the qt_libs_dir shift 
>is not a no-op. Try it :) and if you didn't 
>install qt4-mac-transitional in the same command 
>you'll get errors from rev-upgrade. Or else 
>you'll see that re-built Qt or KDE applications 
>now link to stuff in /opt/local/libexec/qt4 .

Related to the proposed Charm port:

https://trac.macports.org/ticket/46575

If I understand correctly, Charm will create subports ala:

qt5-charm
charm

Is this supposed to be a model for going forward? 
I find the "qt5-" prefix objectionable.

Going forward, I believe we will have the following cases:
1) Projects that work with Qt4 but not Qt5
2) Projects that work with Qt5 but not Qt4
3) Projects that work with either Qt4 or Qt5 but differ in non-trivial ways
4) Projects that work with the same with Qt4 or Qt5

Assuming we have co-installable Qt4 and Qt5 via 
MacPorts, cases 1), 2) and 4) are 
straightforward:  'port:' style dependencies for 
1) and 2) and 'path:' style for 4).

In case 3), I think the upstream development plan 
is important.  If upstream is moving to 
supporting Qt5 and the current differences are 
due to incomplete support, I think it would be 
more appropriate to create a '-devel' version of 
the port until the Qt5 conversion is complete. 
OTOH, there might be rare cases where users might 
need to choose between the Qt4 version (more 
compatible, say) and a Qt5 version (new 
features).  Qt4/Qt5 variants would then be 
appropriate.

FWIW, the project I'm most concerned with, 
MythTV, has had a working build with Qt5 for a 
long time and is encouraging testing but it is 
not recommended for casual users.  AIUI, it was 
not particularly difficult to add Qt5 support 
even though Myth uses Qt extensively for user 
interface (including video rendering) and OS 
abstraction.  When upstream is closer to another 
release (0.28), I plan to create a -devel version 
using Qt5.  Barring show-stoppers, I expect to 
transition to Qt5 exclusively.

Craig