From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 01 Feb 2023 09:49:53 +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 1pN8oU-009tDl-L0 for lore@lore.pengutronix.de; Wed, 01 Feb 2023 09:49:53 +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 1pN8oR-0006zt-NS; Wed, 01 Feb 2023 09:49:51 +0100 Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pN8nz-0006z1-2b; Wed, 01 Feb 2023 09:49:23 +0100 Received: from mol by ptx.hi.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1pN8ny-0003YZ-Oq; Wed, 01 Feb 2023 09:49:22 +0100 Date: Wed, 1 Feb 2023 09:49:22 +0100 From: Michael Olbrich To: Alexander Dahl Message-ID: <20230201084922.GM8218@pengutronix.de> Mail-Followup-To: Alexander Dahl , ptxdist@pengutronix.de References: <2489528.Mdqamz9Hy9@ada> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2489528.Mdqamz9Hy9@ada> X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-Accept-Language: de,en X-Accept-Content-Type: text/plain User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [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 Cc: 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 Hi, On Tue, Jan 31, 2023 at 04:33:00PM +0100, Alexander Dahl wrote: > 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. You can add the dependency in just one layer: Either copy myapp.in to rules/myapp.in in that layer and add the dependency or (if that file is sufficiently complex), create rules/myapp.fixup.in with: ------------------------------------------- ## SECTION=.... config MYAPP select LIBMYLIBA ------------------------------------------- Kconfig will basically just merge the two entries internally. Then run "ptxdist oldconfig" in that layer. You'll get a modified ptxconfig and a ptxconfig.diff with just PTXCONF_LIBMYLIBA=y (and comments). You'll need to run oldconfig whenever the base ptxconfig changes. PTXdist will complain if they are out of sync. This is one of the use-cases I had in mind when I designed the layers in PTXdist. Michael -- 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 |