From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 20 Nov 2023 14:56:11 +0100 Received: from metis.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::104]) by lore.white.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1r54l1-001WZh-0B for lore@lore.pengutronix.de; Mon, 20 Nov 2023 14:56:11 +0100 Received: from localhost ([127.0.0.1] helo=metis.whiteo.stw.pengutronix.de) by metis.whiteo.stw.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1r54l1-0006T0-8F; Mon, 20 Nov 2023 14:56:11 +0100 Received: from mail.thorsis.com ([92.198.35.195]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r54kf-0006S0-SH; Mon, 20 Nov 2023 14:55:50 +0100 Date: Mon, 20 Nov 2023 14:55:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thorsis.com; s=default; t=1700488548; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:content-type:content-type:in-reply-to:in-reply-to: references:references; bh=J2jzJgGIIr+VRSCcD3uHtcXLqZikmmrbS7eabQxg0LA=; b=Llz0CtG05J3UGmwVEu6OLv03Y18dqW7iQhNjSy9K/S/xypLpWbJQm6u4K2oZ1Os4p/iqVb Xz4iCn8O0rGVSROWPJGczS0vgN50kEL7O9tcgIpxwy1OGhIg4L/oU6y0dsf9Z/FqY6Lp8T 7WU9hQ5P1HN3p88SR7oEr7h5o8dhCmn9iIygGBGdQgT7AMX0VhHlFnTlena0GyH12C/Pwc mFq0QV4kMxUXL9KZkSO/4ipPvYvHhkdAXKoETqjLXOxbw0KykGjP2Xx/Mr+cGi/qQ8gdxb k0m6gjg//YWpj1nmKrxr6TpxicOQWYZSEgBZAMfp26bQdMRB8/A4gmqM9l7CxQ== From: Alexander Dahl To: Michael Olbrich Message-ID: <20231120-stopped-bulginess-7410677f82a5@ifak-system.com> Mail-Followup-To: Michael Olbrich , ptxdist@pengutronix.de, Roelf-Erik Carsjens References: <20231017113515.395026-1-ada@thorsis.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on metis.whiteo.stw.pengutronix.de X-Spam-Level: X-Spam-Status: No, score=-2.8 required=4.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.2 Subject: Re: [ptxdist] [RFC PATCH 0/1] building qmake based target packages X-BeenThere: ptxdist@pengutronix.de X-Mailman-Version: 2.1.29 Precedence: list List-Id: PTXdist Development Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: ptxdist@pengutronix.de Cc: Alexander Dahl , Roelf-Erik Carsjens , ptxdist@pengutronix.de Sender: "ptxdist" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: ptxdist-bounces@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false Hello Michael, Am Fri, Nov 10, 2023 at 08:51:01AM +0100 schrieb Michael Olbrich: > On Tue, Oct 17, 2023 at 01:35:14PM +0200, Alexander Dahl wrote: > > Hello everyone, > > > > I currently have some kind of weird requirement: building a target > > package with qmake, but not linking against Qt. It's a fork of RTKlib > > which is itself a university project (with hand written makefiles, but > > not for the part I'm interested in): > > > > https://github.com/rtklibexplorer/RTKLIB/releases/tag/b34h > > > > I actually achieved building it with the attached make rule. Note it > > has a dependency to QT5, but I had to manually add the Qt mkspec file > > ptxdist creates as an option to the _CONF_OPT variable. > > > > Two things are bad about this: > > > > 1.) I don't think it should be necessary to let the make rule set the > > correct mkspec file. There is only one and IMHO ptxdist should handle > > this internally if CONF_TOOL is qmake? > > I'm pretty sure you're calling the wrong qmake here. You need to modify > PATH the same way e.g. rules/qwt5.make does. This works, thanks. (If not setting that, the qmake of my host system was taken. Double checked that by removing that qmake for now.) > > 2.) rather large Qt libraries are installed to the target now. I guess > > I might be able to avoid this by setting 'select QT5 if BUILDTIME' in > > the in rule, but I would have expected HOST_QT5 to be sufficient. This > > does not work however for two reasons: a) ptxdist complains it needs QT5 > > if CONF_TOOL is qmake and b) if I only select HOST_QT5 that mkspec is > > not generated. > > Do you need qmake from qt5 or would qt6 work as well? We already have a > host-qt6 package and if we build the binary there and split out the qmake > config stuff from qt6 into a new cross-qmake package. Tested with 'select QT5' and 'select QT6' now and both work. Only doing 'select HOST_QT5' or 'HOST_QT6' yields this: [ 35/171] started : rtklib-demo5.prepare ptxdist: error: 'rtklib-demo5' uses 'qmake' but does not select 'qt5' or 'qt6' (With ptxdist-2023.03.0 at least.) > It would need to copy the mkspecs from the host package I think before > adding the custom mkspecs stuff. This is not yet in place, right? At least I could not see any related changes between ptxdist-2023.05.0 and master. Greets Alex > > Michael > > > I saw ptxdist having nearly zero packages selecting QT5, and none > > requiring HOST_QT5 (?) so it's difficult to learn from examples here. > > Maybe this usecase is quite esoteric? Don't know. > > > > In the end I would only need qmake, nothing more. That one generates a > > Makefile which is then used to compile the package. > > > > Would take directions to improve ptxdist for qmake based packages. > > > > Greets > > Alex > > > > Alexander Dahl (1): > > WIP: rtklib-demo5: Add new package > > > > rules/rtklib-demo5.in | 23 ++++++++++++++++ > > rules/rtklib-demo5.make | 58 +++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 81 insertions(+) > > create mode 100644 rules/rtklib-demo5.in > > create mode 100644 rules/rtklib-demo5.make > > > > > > base-commit: 90875f8af4f6f1dd9f8eda71df8e8a90866f9839 > > -- > > 2.30.2 > > > > > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |