qmake has no support for generating Makefiles with calls to such
non-standard binaries either [...] - feel free to correct me if I got
it wrong, I sure would like make them coexist).
I have found that there actually is support for this sort of thing.
Whether it's complete and can easily be used in ports, I don't know. But
it works beautifully for me.
I am running both Qt 3 and 4. Qt 3 is installed from ports (and
therefore in /usr/X11R6) while Qt 4 is in a subdirectory of ~. To
properly compile a Qt 4 project, all I have to do is to explicitly run
qmake from Qt 4's directory. The resulting makefile will refer to moc
and uic using their full path names so that when I run gmake, it will
correctly use Qt 4's tools.
So it seems that Qt 3 and 4 can coexist if Qt 4 is simply installed in
another location than /usr/X11R6 - such as usr/X11R6/qt4. Then, the
build system only has to make sure that for Qt 4 based ports, Qt 4's
version of qmake is run. Everything else will work automagically.
But there is an even more elegant solution. As I am sure you know, the
names of all the tools qmake will refer to are specified in qmake.conf
(inside the mkspecs hierarchy). There are lines in there such as:
QMAKE_MOC = $$[QT_INSTALL_BINS]/moc
I changed this to:
QMAKE_MOC = $$[QT_INSTALL_BINS]/moc4
And sure enough, after I re-ran qmake, the makefiles for my project all
referred to moc4. So, Qt 3 and Qt 4 can coexist in /usr/X11R6 as long as
the few tools with conflicting names (qmake, moc, uic) are renamed and
it is made sure that all Qt 4 based ports run qmake4 instead of just qmake.
With that out of the way, what about includes and libs? Well, we're
lucky here as well. All of Qt 3's include files live directly in
/usr/X11R6/include. In Qt 4, they are split among different
subdirectories such as Qt, Qt3Support, QtAssistant, ... So, there are no
conflicts here. The libraries, while not hidden away in subdirectories,
have simply been renamed to libQt3Support.so,
libQtAssistantClient.so, libQtCore.so - no conflicts here either.
The mkspecs hierarchy, at least for me, installs into a top-level
directory along include, lib, which would become /usr/X11R6/mkspecs and
therefore not conflict with Qt 3 either.
So, in conclusion, it seems to me that with the exception of a few
executables, Qt 4 uses different file names and can be installed into
the same hierarchy as Qt 3. Also, after the conflicting tools have been
renamed, a simple patch to qmake.conf should suffice for all Qt 4 based
ports to pick up the rename.
Really, the only thing that needs to be done for every Qt 4 based port
is to make sure that it runs qmake4, not qmake. And this could probably
be handled via a switch in the ports' makefiles.
Maybe I am seeing this too optimistically, but at least to me, it
appears quite straight forward. It might just be that after the Qt 2 ->
Qt 3 transition was so hard, the Trolls have learned ;).
- Bartosz
_______________________________________________
kde-freebsd mailing list
[email protected]
http://freebsd.kde.org/mailman/listinfo/kde-freebsd
