2020. 02. 26. 18:08 keltezéssel, Böszörményi Zoltán írta:
2020. 02. 26. 17:51 keltezéssel, Khem Raj írta:
On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:
2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:
On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán <zbos...@pr.hu> wrote:
2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán <zbos...@pr.hu>
wrote:
2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
Openembedded-core <openembedded-core@lists.openembedded.org> wrote:
The package name exploits sstate.bbclass so it's not added as
implicit dependency to packages.
what is the use of this recipe and why should it be added to core ?
I should have added a cover letter, shouldn't I?
See patch 3/5 in the series for enabling gallium-va in Mesa.
recipe seems to build full libva, so why not just use that instead.
You don't seem to be reading mails from openembedded-devel that
you were cc-ed on.
don't assume things
Understood.
http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html
I am trying to make us thing if -dev package can be used somehow to
avoid this
or have we exhausted all possibilities.
Why is it a problem to exploit sstate.bbclass internals implicitly
by using a *-initial package name for an arbitrary package?
it is not a problem, however, it is a work to keep such setup going and
also it has to be considered always in dependencies etc.
Surely it's not reserved for libgcc-initial and friends.
they are different usecases, libgcc-initial is a veneer/trampoline used
to bootstrap toolchain, and that too we want to remove at every
opportunity we get, we use to have lot of initial recipes and they are
very few left, so we have to be mindful of adding another one.
It solves two problems nicely in one go:
1. by using a different package than libva, the libva-vs-mesa
circular dependency is avoided. mesa needs a crippled libva
(pkgconfig + headers)
to build its VAAPI state tracker and the VAAPI drivers
I see archlinux using full libva for this. how are other distros doing
it? is this problem unique to OE
Fedora also uses the full libva.
However, the chicken-and-egg circular dependency is broken by history
for these distros.
Koji and Mock build one package at a time with all their dependencies
already available from the staging package repository and the results
will be eventually uploaded to the same repository.
Bitbake doesn't have have this loophole to download pre-built dependencies.
Also, somewhere on 01.org or in the libva sources the same solution
I presented in this patchset is suggested:
1. build libva with --disable-glx (it is needed when Mesa SDK is present)
but it's not needed by not depending on mesa in libva-initial
2. build mesa with libva build in (1) as it only needs the pkgconfig files
and the headers
3. build libva with --enable-glx. It's autodetected, set to on with
depending on mesa in the full libva recipe.
Obviusly the same libva recipe can't be used to build mesa that depends on mesa.
2. by using libva-initial as the package name, the per-recipe sysroot issue
is avoided where prepare-sysroot for a 3rd package like
intel-vaapi-driver
would fail because the real libva the crippled variant would install
identical files
right, this is the problem I am afraid of creating almost duplicate packages
Signed-off-by: Böszörményi Zoltán <zbos...@pr.hu>
---
meta/recipes-graphics/libva/libva-2.6.1.inc | 4 +++-
meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
2 files changed, 8 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-graphics/libva/libva-initial_2.6.1.bb
diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
b/meta/recipes-graphics/libva/libva-2.6.1.inc
index ca1386d80b..5b1cdee7e3 100644
--- a/meta/recipes-graphics/libva/libva-2.6.1.inc
+++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
@@ -17,10 +17,12 @@ SECTION = "x11"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
-SRC_URI =
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2";
+SRC_URI =
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2";
SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
SRC_URI[sha256sum] =
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
+S = "${WORKDIR}/libva-${PV}"
+
UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases";
DEPENDS = "libdrm"
diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
new file mode 100644
index 0000000000..828ef6fbca
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,5 @@
+require libva-${PV}.inc
+
+do_install_append () {
+ rm -f ${D}${libdir}/*.so*
+}
--
2.24.1
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
