[Buildroot] [PATCH v3 01/38] package/libdvdcss: add Kodi-specific patches
Yann E. MORIN
yann.morin.1998 at free.fr
Sat Feb 11 16:37:06 UTC 2017
Bernd, All,
On 2017-02-11 17:03 +0100, Bernd Kuhls spake thusly:
> Thomas Petazzoni
> <thomas.petazzoni at free-electrons.com> wrote
> in news:20170209232937.2a071f11 at free-electrons.com:
>
> Hi Thomas,
>
> > Are these .a files still needed after the switch to CMake as the build
> > system for Kodi?
>
> fortunately no.
>
> > Also, for the patches that apply to the libdvdcss, libdvdread and
> > libdvdnav code base, it would be good to know if they have been
> > submitted to the respective upstream projects, or if it's stuff that we
> > may have to keep in Buildroot forever.
>
> Afaics when using the new CMake-based build system of Kodi 17 it will
> build libdvd* itself by using Kodi-specific tarballs:
>
> https://github.com/xbmc/xbmc/blob/Krypton/project/cmake/modules/FindLibDvd.
> cmake#L100
> https://github.com/xbmc/xbmc/blob/Krypton/project/cmake/modules/FindLibDvd.
> cmake#L132
> https://github.com/xbmc/xbmc/blob/Krypton/project/cmake/modules/FindLibDvd.
> cmake#L164
That's just insane that they got rid of their internal copies, to just
re-introduce them a release later... :-(
However, from those files you quoted:
https://github.com/xbmc/xbmc/blob/Krypton/project/cmake/modules/FindLibDvd.cmake#L2
So Kodi actually *can* use external dvdcss, dvdread and dvdnav
libraries. It /just/ needs KODI_DEPENDSBUILD (whjatever that is supposed
to mean... :-/ )
> So we do neither need to patch libdvd* anymore nor provide them as
> dependent packages, KODI_EXTRA_DOWNLOADS can be used to provide the
> tarballs.
>
> First build tests were successful but I would like to be cautious about the
> switch to CMake because I only started to use it today with an x86_64
> toolchain so I have not much experience with it, as of this moment I never
> did a runtime test of the compiled binaries. I hope to find some time for
> this in the coming days but until then you can find my patches here:
>
> https://github.com/bkuhls/buildroot/tree/kodi_cmake
>
> Please note that LibreElec and Gentoo already build Kodi 17 using CMake:
>
> https://github.com/LibreELEC/LibreELEC.tv/blob/libreelec-
> 8.0/packages/mediacenter/kodi/package.mk#L34
>
> https://gitweb.gentoo.org/repo/gentoo.git/tree/media-tv/kodi/kodi-
> 17.0.ebuild#n161
>
> Do we still have external toolchains based on uClibc 0.9.33.2?
> If yes, we need to keep
> https://git.buildroot.net/buildroot/tree/package/kodi/0003-ALSA-fix-device-
> change-event-support.patch and add CMake checks for eventfd_read &
> eventfd_write.
I'd say we should not care about uClibc < 1.0, it's dead.
So, either we mark Kodi as !uclibc, or we let the user keep the pieces
if they are stuck with such an antediluvian toolchain. Get into the 21st
century, man... ;-]
Actually, I think we should start detecting such old toolchains and
refuse to use them.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list