Took a while for me to figure out what was wrong as I did have QT installed. The switch should be named --enable-kde or then configure should inform that it's looking for kde libraries, not just plain QT.
Should probably be called --enable-kde3 actually, given that Qt 4 will have D-BUS bindings.
*** Bug 1711 has been marked as a duplicate of this bug. ***
Created attachment 3261 [details] [review] BRANCH_1_0 patch 2/2: Fix locking in _cairo_ft_scaled_font_text_to_glyphs this patch also cleans up the Qt configuration logic a bit
Comment on attachment 3261 [details] [review] BRANCH_1_0 patch 2/2: Fix locking in _cairo_ft_scaled_font_text_to_glyphs I'd prefer have_qt be set to just "no" rather than with the parens saying QTDIR not set; you could add a no_qt_explanation set to "" or "QTDIR not set" then stick that variable in the end-of-configure summary for the same effect. You need to handle the case that enable_qt=auto in addition to enable_qt=yes/enable_qt=no. The default is auto which means "use it if it's there" while "yes" means "error if we can't use it" and "no" means "don't ever use it" Spec file authors for example use --enable-qt=yes to require that the build environment have qt, or --enable-qt=no to ignore qt even if the build env has it. To handle auto you might want to go back to the original arrangement of the configure script and just change how qt is detected.
Created attachment 3277 [details] ssh public key This patch was tested for all cases of --enable-qt with - QTDIR set - QTDIR not set - QTDIR set to wrong directory this should cover everything
Comment on attachment 3277 [details] ssh public key Looks great, thanks
Looks fixed. Closing
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.