On 4/14/2023 16:43, Andrew Davis wrote:
On 4/14/23 3:54 PM, Denys Dmytriyenko wrote:
On Wed, Apr 12, 2023 at 04:28:45PM -0500, Andrew Davis wrote:
On 4/12/23 4:25 PM, Denys Dmytriyenko wrote:
On Wed, Apr 12, 2023 at 04:08:50PM -0500, Andrew Davis wrote:
On 4/12/23 3:43 PM, Denys Dmytriyenko wrote:
On Wed, Apr 12, 2023 at 01:42:41PM -0500, Andrew Davis via
lists.yoctoproject.org wrote:
Neither of recipes nor their ABI is all that stable. OpenGL might be
slightly more stable, but that is not what these provide anymore.
Remove these.
This is not what you think it is... :) Actually, Rogue recipes
should be added
to the list.
This is specific to signatures/shared state. The ABI in this case
is libgles
and libegl (which are stable) and tells bitbake to avoid
rebuilding generic
apps depending on these packages between platfoms in the same
architecture.
These do not provide those API anymore, Mesa does. And nothing
should depend
on the KM package other than the UM libs.
Still doesn't matter - if you have Mesa depend on these, you still
need them
listed in here to avoid rebuilding Mesa from one platform to
another. And
everything else downstream.
We *want* Mesa to be rebuilt if these change, these do not provide a
stable ABI
anymore, it can and does change, sometimes between platforms (SGX KM
-> UM is
based on plat).
The name of the variable may be confusing. It's not about rebuilding
Mesa once
you make changes to the KM/UM pieces - that will happen automatically
if the
dependencies are tracked properly.
This variable is about re-use of the dependant generic packages. The
issue it
is trying to solve is when you have machine-specific packages early in
the
dependecy tree, everything down the dependency tree that depends on these
packages will be treated as machine-specific, even if they are
generic. Since
bitbake will try to play safe here, you have to tell it otherwise.
Again, this is not about rebuilds of a dependent component between
changes.
This is about rebuilds of a dependent component between different
machines
(platforms) w/o making any changes.
For example, Wayland, Weston and all Qt5 modules are generic and
should be
re-used from shared state across all our Aarch64 platforms, but that's
not the
case and they are being rebuilt for each and every platform again and
again.
I've done some experiments locally - back when SGX/Rogue UM libs provided
libgles, libegl, libgbm (which API/ABI are supposed to be stable!), you
certainly wanted to have them listed in this
SIGGEN_EXCLUDERECIPES_ABISAFE
list. Now, those ABIs have shifted to Mesa and we do mark that package as
machine-specific (I had to add PACKAGE_ARCH = "${MACHINE_ARCH}" when
redoing
Reese's patches - see v8 changes section at [1]). With that in mind, this
variable now has to list Mesa instead of individual UM packages - the
patch
is coming.
So then we are saying the same thing, the UM libs should not be listed
here.
This patch should go in then, and another one that adds Mesa to the list
can go in after.
If that is fine, then the first 5 patches in this series should be good
to go.
Denys, is there a follow on patch to this one that will correct your
comments? Should I hold off on applying this patch until your patch is
ready, or go ahead and apply it so that you have a basis for your patch?
Andrew
--
Ryan Eatmon [email protected]
-----------------------------------------
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16406):
https://lists.yoctoproject.org/g/meta-ti/message/16406
Mute This Topic: https://lists.yoctoproject.org/mt/98225808/21656
Group Owner: [email protected]
Unsubscribe:
https://lists.yoctoproject.org/g/meta-ti/leave/6695321/21656/1393940836/xyzzy
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
