[OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

Wed Feb 26 17:14:55 UTC 2020

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 <zboszor at 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 <zboszor at 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 at 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 <zboszor at 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 at lists.openembedded.org
>>>>>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>>>>>
>>>>>
>>>
> 