You are here

Recent Qt-related changes in build system

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: 
rncbc's picture

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

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.

rncbc's picture

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_qtdirs variable, 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