From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 31 Jan 2023 16:34:01 +0100 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by lore.white.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pMse2-0092Ca-Q3 for lore@lore.pengutronix.de; Tue, 31 Jan 2023 16:34:01 +0100 Received: from localhost ([127.0.0.1] helo=metis.ext.pengutronix.de) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1pMse0-0002Ch-6p; Tue, 31 Jan 2023 16:34:00 +0100 Received: from mail.thorsis.com ([92.198.35.195]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pMsdU-0002CY-Cm for ptxdist@pengutronix.de; Tue, 31 Jan 2023 16:33:29 +0100 From: Alexander Dahl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thorsis.com; s=default; t=1675179207; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=hl1eMYVQG4okxSJr1OpcvW+AlKz2RJaZVUrmgFxAdQQ=; b=gw2KMpYwPetV5OemJo4CbSIU1VsAHUfRgY6He+JaxsYOZT+cPs6hUl2ZqXLlLHp14dWOrr AQSQCern/R3Ux9yrH7ozAbe/zX8Gglz+RXV15wgeVapLwCyWvOaTYrQOxmlPPbXoMeYVdB 7wN813NyPKJCN/7W/UtmqI+zg8p4a1KoUUrTWAsN1DqDwSH/5ovofTQg6kcm7cwOuqqK4g kAbdkDCmpr8SiPvksIzomDmcESvpgtY5kKzbxMk5A038MAiUm0A7os0T1scrfonpsG183N ziS+FbPCUSIz2QELS0OGoVgNzUcpa1SazED4z1wl8zQwDTzXE8r5s2lGvB/F7Q== To: ptxdist@pengutronix.de Date: Tue, 31 Jan 2023 16:33:00 +0100 Message-ID: <2489528.Mdqamz9Hy9@ada> Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Clacks-Overhead: GNU Terry Pratchett X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on metis.ext.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_PASS,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Subject: [ptxdist] target package dependency to platform 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 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.ext.pengutronix.de); SAEximRunCond expanded to false Hei hei, I'm stuck with a problem where I can not find an elegant solution for. Let me describe. I have a layered BSP. The base layer has different platformconfigs for hardware targets with different SoC architectures, let's say the PTXCONF_PLATFORM is "pla" on one and "plb" on the other. (I can not build the whole stuff for one platform only, two platforms are strictly required.) There is a more or less ordinary CMake based target application in the base layer, let's say in "base/rules/myapp.{in,make}", because that application is needed on both platforms. The two upper layers select the different platforms with different toolchains and both also enable "myapp". (Yes, I could also have it all in a single layer BSP with two working copies and building one platform per working copy. Doesn't change the problem.) myapp depends on multiple libraries, some of them hardware specific. So for platform "pla" it needs "libmyliba" and for platform "plb" it does not. In "base/rules/myapp.make" I pass PTXCONF_PLATFORM as a build time option to CMake like this: MYAPP_CONF_OPT += -DHARDWARE_NAME=$(PTXCONF_PLATFORM) Depending on "HARDWARE_NAME" I call `find_package(myliba)` in "CMakeLists.txt" of myapp. I could do a "select LIBMYLIBA" in "base/rules/myapp.in" unconditionally, and that would make the build successful. In the BSP for platform "pla" CMake would look for libmyliba and link and on the target it would be used at runtime just fine. In the BSP for platform "plb" CMake would not look for it, would not complain, myapp would run happily on the target without using libmyliba just fine. However, libmyliba would be built for platform "plb" and it would be copied over to "plb" target and take space, but never be used there. Build time for it would be completely wasted. Even worse, user might find it on target and wonder what it means, although it's useless on platform "plb". I could _not_ add that "select LIBMYLIBA" and build would fail for target "pla" dependending on package build order. Also dependencies in opkg packages would not be correct then. What also does not work is this (in "base/rules/myapp.in"): select LIBMYLIBA if PLATFORM = "pla" This is valid syntax from Kconfig point of view, but PLATFORM is just not defined here at all. I assume configs/ptxconfig and configs/platform-pla/ platformconfig are somewhat distinct Kconfig spaces and one can not simply reference to Kconfig options from the other side. Interestingly I can do `ptxdist print PTXCONF_PLATFORM` and `ptxdist print PTXCONF_MYAPP` and ptxdist prints variables from both Kconfig spaces. Also I can successfully use both in base/rules/myapp.make and that's at least somewhat misleading. (Misleading as in: Why can I use both here but not there?) That's where I'm stuck. Of course I looked through ptxdist git sources to find hints on how to solve this dilemma, but without luck. Would be happy if anyone could give a hint or suggest a solution. Greets Alex