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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
