From: Alexander Dahl <ada@thorsis.com>
To: ptxdist@pengutronix.de
Subject: [ptxdist] target package dependency to platform
Date: Tue, 31 Jan 2023 16:33:00 +0100 [thread overview]
Message-ID: <2489528.Mdqamz9Hy9@ada> (raw)
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
next reply other threads:[~2023-01-31 15:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-31 15:33 Alexander Dahl [this message]
2023-02-01 8:49 ` Michael Olbrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2489528.Mdqamz9Hy9@ada \
--to=ada@thorsis.com \
--cc=ptxdist@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox