Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752075AbbKBDUr (ORCPT ); Sun, 1 Nov 2015 22:20:47 -0500 Received: from mga01.intel.com ([192.55.52.88]:14503 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751957AbbKBDUq (ORCPT ); Sun, 1 Nov 2015 22:20:46 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,232,1444719600"; d="scan'208,223";a="592255258" From: Thiago Macieira To: Alexey Brodkin Cc: "mmarek@suse.com" , "linux-kernel@vger.kernel.org" Subject: Re: make xconfig no longer works in Fedora Date: Sun, 01 Nov 2015 21:20:43 -0600 Message-ID: <1540852.ryHORPH4E7@tjmaciei-mobl4> Organization: Intel Corporation User-Agent: KMail/4.14.10 (Linux/4.2.1-1-desktop; KDE/4.14.12; x86_64; ; ) In-Reply-To: <1446295161.4394.81.camel@synopsys.com> References: <1446295161.4394.81.camel@synopsys.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart7092456.7SHRv1n29T" Content-Transfer-Encoding: 7Bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3064 Lines: 85 This is a multi-part message in MIME format. --nextPart7092456.7SHRv1n29T Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Saturday 31 October 2015 12:39:21 Alexey Brodkin wrote: > Hi Thiago, > > I noticed that with your patch "Update the buildsystem for KConfig finding > Qt" > I cannot use "make xconfig" in Fedora 22 any longer. Hello Alexey > The reason why xconfig target fails is in Fedora (at least its recent > versions) > there's no "qmake". Instead there're "qmake-qt4" and/or > "qmake-qt5" depending on which Qt packages are installed. Hmm... you're right. There's no check for a program with a different name in the new Makefile. I apologise, I never tested that case. Fedora is knowingly deviating from Qt Project recommendations. I will fix this, but please file a bug report against their Qt packages so there's some pressure to adopt a standard solution that everyone else already does. > But IMHO it would be really nice if we don't break things that used to > work. Right. Can you try the attached patch to see if it solves the problem for you? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center --nextPart7092456.7SHRv1n29T Content-Disposition: attachment; filename="0001-Attempt-to-find-qmake-qt5-and-qmake-qt4-if-no-qmake-.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="0001-Attempt-to-find-qmake-qt5-and-qmake-qt4-if-no-qmake-.patch" >From fd7d0a2137ece3294703878fc1667e5196f766b9 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Sun, 1 Nov 2015 21:12:53 -0600 Subject: [PATCH 1/1] Attempt to find qmake-qt5 and qmake-qt4 if no "qmake" is found in $PATH The Qt Project recommendation is that there should always be a "qmake" binary and it should never be renamed. If it's necessary to handle multiple Qt versions, the Qt Project recommends using qtchooser. Unfortunately, some distros do not follow the recommendation, so we need to test different possibilities... Signed-off-by: Thiago Macieira --- scripts/kconfig/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile index 33c4994..0511557 100644 --- a/scripts/kconfig/Makefile +++ b/scripts/kconfig/Makefile @@ -227,7 +227,9 @@ $(obj)/.tmp_qtcheck: $(src)/Makefile # Qt needs some extra effort... $(obj)/.tmp_qtcheck: @set -e; $(kecho) " CHECK qt"; \ - qtver=`qmake -query QT_VERSION` || { \ + qtver=`qmake -query QT_VERSION` || \ + qtver=`qmake-qt5 -query QT_VERSION` || \ + qtver=`qmake-qt4 -query QT_VERSION` || { \ echo >&2 "*"; \ echo >&2 "* qmake failed."; \ echo >&2 "*"; \ -- 2.6.2 --nextPart7092456.7SHRv1n29T-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/