Main menu
You are here
Recent Qt-related changes in build system
10 January, 2014 - 12:11 — schivmeister
Hi there Rui
With your latest changes across most of the q* suite I noticed there is now some preparation for qt5. However, this proved to be a problem on systems where both qt4 and qt5 are installed and the latter is default (meaning, the dirs are not suffixed with a number).
It would be better if you did not hardcode "qt" in configure, but instead picked up the version from an env var such as QT_SELECT or from the default conf. [1] I have only hacked qsampler, [2] but will wait for a response from you before I go on sed'ing the configure for the rest of your apps.
Happy new year and thanks for all your work!
[1] http://www.linuxfromscratch.org/blfs/view/svn/general/qtchooser.html
[2] https://aur.archlinux.org/packages/qs/qsampler/PKGBUILD
Forums:
re. Recent Qt-related changes in build system
this is all very distro dependant, if i may say, and very qt5 specific too :/
if both qt5 and qt4 are installed on your system and the default is qt5, then i'd suggest you to try
./configure --enable-qt5...or
./configure --disable-qt4...in either case, if qt5 is not the system selected default, then maybe you'll need something like this:
./configure --enable-qt5 --with-qt=/opt/Qt5.x.y/5.x.y/gcc ...let me remind you that qtractor is currently recommended for packaging as a qt4 only application;
building it as a qt5 one, although perfectly functional and operational, it will end as an utterly crippled audio/MIDI application on some rather important features, mostly on the LV2 plugin GUI support
that said, only the lv2_external_ui (unofficial) extension is then supported; there will be NO libSUIL wrapped amenities whatsoever, that meaning that most if not all native GTK+, X11 or even Qt4 plugin GUIs will be ditched out or completely forbidden--some will even crash on show.
hth.
cheers
qt may be qt4 or qt5
Thanks for the prompt response! I was actually referring to a system where qt5 is default, but qt4 is also installed. Programs should still pick up the version they need; I don't particularly want to build anything against qt5 (/usr/lib/qt), I want to build against qt4 (/usr/lib/qt4) and that is why it fails.
In some cases both versions have their directories suffixed (e.g. /usr/lib/qt4 and /usr/lib/qt5) while in others either one is not (e.g. /usr/lib/qt can be 4 or 5). Yes, this is really qt-specific and, to some extent, distro-dependent as well. Just wondering whether there should be a cleaner way to handle this.
re. qt may be qt4 or qt5
Just wondering whether there should be a cleaner way to handle this.
if you find one please let me know it :)
i know that you're somewhat suggesting to drop the "qt" particle from
ac_qtdirsvariable, yes... however that thing is there due to debian idiosyncrasy, so to speak :) you can safely remove it as i think was found hacked on the link [2] above.cheers
Add new comment