Re: [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe

[Jussi Kukkonen <jussi.kukkonen@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 3087 bytes --]

On 27 November 2015 at 13:04, Maxin B. John <maxin.john@intel.com> wrote:

> libjpeg-turbo has same API/ABI as libjpeg. It is relatively
> faster in JPEG compression/decompression than libjpeg.
>
> [YOCTO #8628]
>
> Signed-off-by: Maxin B. John <maxin.john@intel.com>
> ---
>  meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40
> ++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>  create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
>
> diff --git a/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
> b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
> new file mode 100644
> index 0000000..e79f800
> --- /dev/null
> +++ b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
> @@ -0,0 +1,40 @@
> +DESCRIPTION = "libjpeg-turbo is a derivative of libjpeg that uses SIMD
> instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and
> decompression"
> +HOMEPAGE = "http://libjpeg-turbo.org/"
> +
> +LICENSE = "BSD-3-Clause"
> +LIC_FILES_CHKSUM =
> "file://cdjpeg.h;endline=12;md5=cad955d15145c3fdceec6855e078e953 \
> +
> file://jpeglib.h;endline=14;md5=dfc803dc51ae21178d1376ec73c4454d \
> +
> file://djpeg.c;endline=9;md5=e93a8f2061e8a0ac71c7a485c10489e2 \
> +"
> +
> +DEPENDS = "nasm-native"
> +
> +BASEPV = "${@d.getVar('PV',True).split('+')[1]}"
> +
> +SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${BASEPV}.tar.gz"
> +SRC_URI[md5sum] = "b1f6b84859a16b8ebdcda951fa07c3f2"
> +SRC_URI[sha256sum] =
> "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08"
> +
> +S = "${WORKDIR}/${BPN}-${BASEPV}"
> +
> +# Drop-in replacement for jpeg
> +PROVIDES = "jpeg"
> +RPROVIDES_${PN} += "jpeg"
> +RREPLACES_${PN} += "jpeg"
> +RCONFLICTS_${PN} += "jpeg"
> +
> +inherit autotools pkgconfig
> +
> +EXTRA_OECONF = "--with-jpeg8 "
>

It's true that this is closest to what we currently provide but my
understanding of the libjpeg changes is this:
* Both versions 7 and 8 encoders can produce files that are incompatible
with decoders of previous versions
* The major additions in 7 and 8 we're never actually accepted at the
relevant standards body
* most importantly, my impression is that everyone else is using version 6b
(this is also jpeg-turbo upstream default)

I suggest we default to _not_  supporting jpeg8 or jpeg7.

Jussi

+
> +PACKAGES =+ "jpeg-tools libturbojpeg"
> +
> +DESCRIPTION_jpeg-tools = "The jpeg-tools package includes client programs
> to access libjpeg functionality.  These tools allow for the compression,
> decompression, transformation and display of JPEG files and benchmarking of
> the libjpeg library."
> +FILES_jpeg-tools = "${bindir}/*"
> +
> +FILES_libturbojpeg = "${libdir}/libturbojpeg.so"
> +INSANE_SKIP_libturbojpeg = "dev-so"
> +
> +BBCLASSEXTEND = "native"
> +
> +LEAD_SONAME = "libjpeg.so.8"
> --
> 2.4.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 4672 bytes --]