[Buildroot] [PATCH] jpeg-turbo: new package

[Buildroot] [PATCH] jpeg-turbo: new package

[Murat Demirten]

From: Murat Demirten <mdemirten@yh.com.tr>

Signed-off-by: Murat Demirten <mdemirten@yh.com.tr>
---
 package/Config.in                |    1 +
 package/jpeg-turbo/Config.in     |   26 ++++++++++++++++++++++++++
 package/jpeg-turbo/jpeg-turbo.mk |   23 +++++++++++++++++++++++
 3 files changed, 50 insertions(+), 0 deletions(-)
 create mode 100644 package/jpeg-turbo/Config.in
 create mode 100644 package/jpeg-turbo/jpeg-turbo.mk

diff --git a/package/Config.in b/package/Config.in
index ca8fc96..5a23f66 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -336,6 +336,7 @@ source "package/gtk2-engines/Config.in"
 source "package/gtk2-themes/Config.in"
 source "package/imlib2/Config.in"
 source "package/jpeg/Config.in"
+source "package/jpeg-turbo/Config.in"
 source "package/libart/Config.in"
 source "package/libdmtx/Config.in"
 source "package/libdrm/Config.in"
diff --git a/package/jpeg-turbo/Config.in b/package/jpeg-turbo/Config.in
new file mode 100644
index 0000000..a398079
--- /dev/null
+++ b/package/jpeg-turbo/Config.in
@@ -0,0 +1,26 @@
+config BR2_PACKAGE_JPEG_TURBO
+ bool "jpeg-turbo"
+ help
+   It is a derivative of libjpeg that uses SIMD instructions
+   (MMX, SSE2, NEON) to accelerate baseline JPEG compression
+   and decompression on x86, x86-64, and ARM systems.
+
+   http://libjpeg-turbo.virtualgl.org
+
+choice
+ prompt "libjpeg api version"
+ default BR2_PACKAGE_JPEG_TURBO_APIVERSION_80
+ depends on BR2_PACKAGE_JPEG_TURBO
+ help
+   Selects libjpeg compatible api version.
+
+config BR2_PACKAGE_JPEG_TURBO_APIVERSION_62
+ bool "62"
+
+config BR2_PACKAGE_JPEG_TURBO_APIVERSION_70
+ bool "70"
+
+config BR2_PACKAGE_JPEG_TURBO_APIVERSION_80
+ bool "80"
+
+endchoice
diff --git a/package/jpeg-turbo/jpeg-turbo.mk b/package/jpeg-turbo/
jpeg-turbo.mk
new file mode 100644
index 0000000..7cfd8c1
--- /dev/null
+++ b/package/jpeg-turbo/jpeg-turbo.mk
@@ -0,0 +1,23 @@
+#############################################################
+#
+# jpeg-turbo
+#
+#############################################################
+JPEG_TURBO_VERSION = 1.2.0
+JPEG_TURBO_SITE = http://$(BR2_SOURCEFORGE_MIRROR).
dl.sourceforge.net/sourceforge/libjpeg-turbo
+JPEG_TURBO_SOURCE = libjpeg-turbo-$(JPEG_TURBO_VERSION).tar.gz
+
+ifeq ($(BR2_PACKAGE_JPEG_TURBO_APIVERSION_80),y)
+ JPEG_TURBO_CONF_ENV += JPEG_LIB_VERSION=80
+endif
+
+ifeq ($(BR2_PACKAGE_JPEG_TURBO_APIVERSION_70),y)
+ JPEG_TURBO_CONF_ENV += JPEG_LIB_VERSION=70
+endif
+
+ifeq ($(BR2_PACKAGE_JPEG_TURBO_APIVERSION_62),y)
+ JPEG_TURBO_CONF_ENV += JPEG_LIB_VERSION=62
+endif
+
+$(eval $(call AUTOTARGETS))
+$(eval $(call AUTOTARGETS,host))
-- 
1.7.5.4
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120603/01f50de5/attachment.html>

[Buildroot] [PATCH] jpeg-turbo: new package

[Thomas Petazzoni]

Hello,

Le Sun, 3 Jun 2012 05:57:46 +0300,
Murat Demirten <mdemirten@yh.com.tr> a ?crit :

> --- /dev/null
> +++ b/package/jpeg-turbo/Config.in
> @@ -0,0 +1,26 @@
> +config BR2_PACKAGE_JPEG_TURBO
> + bool "jpeg-turbo"

Indentation should be one tab.

> + help

Here as well.

> +   It is a derivative of libjpeg that uses SIMD instructions
> +   (MMX, SSE2, NEON) to accelerate baseline JPEG compression
> +   and decompression on x86, x86-64, and ARM systems.
> +
> +   http://libjpeg-turbo.virtualgl.org

Indentation should be one tab + two spaces (for the help text)

> +choice
> + prompt "libjpeg api version"

Fix indentation everywhere :)

> --- /dev/null
> +ifeq ($(BR2_PACKAGE_JPEG_TURBO_APIVERSION_62),y)
> + JPEG_TURBO_CONF_ENV += JPEG_LIB_VERSION=62
> +endif
> +
> +$(eval $(call AUTOTARGETS))
> +$(eval $(call AUTOTARGETS,host))

There's no need to have a host variant of this package I think. 

Also, your patch is line-wrapped, so it cannot easily be applied. Could
you fix your e-mail client, or better, use git send-email to send your
patch?

Thanks a lot for your contribution!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] jpeg-turbo: new package

[Murat Demirten]

Hi,

You're right, host package not important even if you're trying to build a
filesystem for x86 platform because of the one-to-one compatibility of
jpeg-turbo with libjpeg, I'll remove it.

When I start to prepare .mk for jpeg-turbo, I see that there is a need for
new dependency management option like "Provides: jpeg" in professional
package management formats.

Suppose that we built the jpeg-turbo and later we want to build tiff
package. In this case, jpeg turbo will build and it replace jpeg-turbo's
libjpeg.soXX files. For this reason, we have to build jpeg-turbo again to
replace the libraries with correct ones.

Is there any plan to address this issue in future? We just see that
jpeg-turbo a lot faster than libjpeg especially on embedded environments.

(I will send a patch with git send-email, previous one is the result of a
firewall which blocking outgoing smtp and webmail client)

2012/6/3 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

> Hello,
>
> Le Sun, 3 Jun 2012 05:57:46 +0300,
> Murat Demirten <mdemirten@yh.com.tr> a ?crit :
>
> > --- /dev/null
> > +++ b/package/jpeg-turbo/Config.in
> > @@ -0,0 +1,26 @@
> > +config BR2_PACKAGE_JPEG_TURBO
> > + bool "jpeg-turbo"
>
> Indentation should be one tab.
>
> > + help
>
> Here as well.
>
> > +   It is a derivative of libjpeg that uses SIMD instructions
> > +   (MMX, SSE2, NEON) to accelerate baseline JPEG compression
> > +   and decompression on x86, x86-64, and ARM systems.
> > +
> > +   http://libjpeg-turbo.virtualgl.org
>
> Indentation should be one tab + two spaces (for the help text)
>
> > +choice
> > + prompt "libjpeg api version"
>
> Fix indentation everywhere :)
>
> > --- /dev/null
> > +ifeq ($(BR2_PACKAGE_JPEG_TURBO_APIVERSION_62),y)
> > + JPEG_TURBO_CONF_ENV += JPEG_LIB_VERSION=62
> > +endif
> > +
> > +$(eval $(call AUTOTARGETS))
> > +$(eval $(call AUTOTARGETS,host))
>
> There's no need to have a host variant of this package I think.
>
> Also, your patch is line-wrapped, so it cannot easily be applied. Could
> you fix your e-mail client, or better, use git send-email to send your
> patch?
>
> Thanks a lot for your contribution!
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot




-- 
Murat Demirten
Genel M?d?r
http://www.yh.com.tr
(212) 292 04 46 - 113
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120603/a8622f1a/attachment.html>

[Buildroot] [PATCH] jpeg-turbo: new package

[Samuel Martin]

Hi Murat, all,

2012/6/3 Murat Demirten <mdemirten@yh.com.tr>
>
> Hi,
>
> You're right, host package not important even if you're trying to build a filesystem for x86 platform because of the one-to-one compatibility of jpeg-turbo with libjpeg, I'll remove it.
>
> When I start to prepare .mk for jpeg-turbo, I see that there is a need for new dependency management option like "Provides: jpeg" in professional package management formats.

You're right about that,?I've just noticed that testing your patch.

AFAIK, there is no such infrastructure in place in BR to handle this.
Some other distro like gentoo has a virtual package mechanism.

I think such a thing can be quite easily handle in BR:

at the Config.in level:

config BR2_PACKAGE_VIRTUAL_JPEG
? ? bool "jpeg support"
if?BR2_PACKAGE_VIRTUAL_JPEG
choice
...
config BR2_PACKAGE_VIRTUAL_JPEG_LIBJPEG
? ? bool "libjpeg"
? ? select
config?BR2_PACKAGE_VIRTUAL_JPEG_JPEG_TURBO
? ? bool "jpeg-turbo"
...
endchoice
endif

if?BR2_PACKAGE_VIRTUAL_JPEG_LIBJPEG
source package/jpeg/Config.in
endif

if?BR2_PACKAGE_VIRTUAL_JPEG_JPEG_TURBO
source package/jpeg-turbo/Config.in
endif


at the *.mk level:

virtual-jpeg.mk:
# standard gentarget should do the job, no need for
source/version/site variables
VIRTUAL_JPEG_DEPENDENCY = \
? $(if $(BR2_PACKAGE_LIBJPEG),libjpeg) \
? $(if $(BR2_PACKAGE_JPEG_TURBO),jpeg-turbo)\

$(eval $(call GENTARGETS))

then all packages depending on jpeg should be ajdust to depends on virtual-jpeg.


BTW,?this has just popped up out my mind and need more careful thoughts


I don't know which solution is the best between?a virtual package
mechanism or a "PROVIDE" variable mechanism.


>
> Suppose that we built the jpeg-turbo and later we want to build tiff package. In this case, jpeg turbo will build and it replace jpeg-turbo's libjpeg.soXX files. For this reason, we have to build jpeg-turbo again to replace the libraries with correct ones.
>
> Is there any plan to address this issue in future? We just see that jpeg-turbo a lot faster than libjpeg especially on embedded environments.

Do you have any bench?
I'd like to see that ;-)

>
>
> (I will send a patch with git send-email, previous one is the result of a firewall which blocking outgoing smtp and webmail client)
>
>
Again, thx for contributing to BR,


Cheers,


--
Sam

[Buildroot] [PATCH] jpeg-turbo: new package

[Murat Demirten]

Hi,

Your solution will work. Adding a PROVIDES mechanism need more work (like
the what is provides-default of jpeg?). I'm not changing anything in patch
now. I'm not sure about that to add a generic PROVIDES mechanism because it
will increase the buildroot complexity if only used by jpeg-turbo. When we
see that there are more packages like this, we have to add generic PROVIDES
mechanism.

jpeg-turbo's performance gain depends to type of images you're working on
too. We tested it on mips and arm platform (yes, it make difference on mips
too) and it is %30-%50 times faster than libjpeg (I don't have the exact
results now). It is a big difference when you have to make lots of jpeg
decompression in your program.

I sent the same patch again with correct formatting.

2012/6/3 Samuel Martin <s.martin49@gmail.com>

> Hi Murat, all,
>
> 2012/6/3 Murat Demirten <mdemirten@yh.com.tr>
> >
> > Hi,
> >
> > You're right, host package not important even if you're trying to build
> a filesystem for x86 platform because of the one-to-one compatibility of
> jpeg-turbo with libjpeg, I'll remove it.
> >
> > When I start to prepare .mk for jpeg-turbo, I see that there is a need
> for new dependency management option like "Provides: jpeg" in professional
> package management formats.
>
> You're right about that, I've just noticed that testing your patch.
>
> AFAIK, there is no such infrastructure in place in BR to handle this.
> Some other distro like gentoo has a virtual package mechanism.
>
> I think such a thing can be quite easily handle in BR:
>
> at the Config.in level:
>
> config BR2_PACKAGE_VIRTUAL_JPEG
>     bool "jpeg support"
> if BR2_PACKAGE_VIRTUAL_JPEG
> choice
> ...
> config BR2_PACKAGE_VIRTUAL_JPEG_LIBJPEG
>     bool "libjpeg"
>     select
> config BR2_PACKAGE_VIRTUAL_JPEG_JPEG_TURBO
>     bool "jpeg-turbo"
> ...
> endchoice
> endif
>
> if BR2_PACKAGE_VIRTUAL_JPEG_LIBJPEG
> source package/jpeg/Config.in
> endif
>
> if BR2_PACKAGE_VIRTUAL_JPEG_JPEG_TURBO
> source package/jpeg-turbo/Config.in
> endif
>
>
> at the *.mk level:
>
> virtual-jpeg.mk:
> # standard gentarget should do the job, no need for
> source/version/site variables
> VIRTUAL_JPEG_DEPENDENCY = \
>   $(if $(BR2_PACKAGE_LIBJPEG),libjpeg) \
>   $(if $(BR2_PACKAGE_JPEG_TURBO),jpeg-turbo)\
>
> $(eval $(call GENTARGETS))
>
> then all packages depending on jpeg should be ajdust to depends on
> virtual-jpeg.
>
>
> BTW, this has just popped up out my mind and need more careful thoughts
>
>
> I don't know which solution is the best between a virtual package
> mechanism or a "PROVIDE" variable mechanism.
>
>
> >
> > Suppose that we built the jpeg-turbo and later we want to build tiff
> package. In this case, jpeg turbo will build and it replace jpeg-turbo's
> libjpeg.soXX files. For this reason, we have to build jpeg-turbo again to
> replace the libraries with correct ones.
> >
> > Is there any plan to address this issue in future? We just see that
> jpeg-turbo a lot faster than libjpeg especially on embedded environments.
>
> Do you have any bench?
> I'd like to see that ;-)
>
> >
> >
> > (I will send a patch with git send-email, previous one is the result of
> a firewall which blocking outgoing smtp and webmail client)
> >
> >
> Again, thx for contributing to BR,
>
>
> Cheers,
>
>
> --
> Sam
>



-- 
Murat Demirten
Genel M?d?r
http://www.yh.com.tr
(212) 292 04 46 - 113
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120603/82159ee8/attachment-0001.html>

[Buildroot] [PATCH] jpeg-turbo: new package

[Peter Korsgaard]

>>>>> "Murat" == Murat Demirten <mdemirten@yh.com.tr> writes:

 Murat> Hi,

 Murat> Your solution will work. Adding a PROVIDES mechanism need more
 Murat> work (like the what is provides-default of jpeg?). I'm not
 Murat> changing anything in patch now. I'm not sure about that to add a
 Murat> generic PROVIDES mechanism because it will increase the
 Murat> buildroot complexity if only used by jpeg-turbo. When we see
 Murat> that there are more packages like this, we have to add generic
 Murat> PROVIDES mechanism.

 Murat> jpeg-turbo's performance gain depends to type of images you're
 Murat> working on too.  We tested it on mips and arm platform (yes, it
 Murat> make difference on mips too) and it is %30-%50 times faster than
 Murat> libjpeg (I don't have the exact results now).  It is a big
 Murat> difference when you have to make lots of jpeg decompression in
 Murat> your program.

Is there any reason to NOT use jpeg-turbo? Isn't it source level
compatible with the "normal" libjpeg?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] jpeg-turbo: new package

[Murat Demirten]

Yes, jpeg-turbo is source compatible with libjpeg and some distributions
(including Ubuntu, Fedora, Gentoo) start to ship it for the default libjpeg.

Please note that, jpeg-turbo and TurboJPEG-IPP is not the same, TurboJPEG
has some disadvantages on new 64 bit systems and it's development stopped.

2012/6/4 Peter Korsgaard <jacmet@uclibc.org>

> >>>>> "Murat" == Murat Demirten <mdemirten@yh.com.tr> writes:
>
>  Murat> Hi,
>
>  Murat> Your solution will work. Adding a PROVIDES mechanism need more
>  Murat> work (like the what is provides-default of jpeg?). I'm not
>  Murat> changing anything in patch now. I'm not sure about that to add a
>  Murat> generic PROVIDES mechanism because it will increase the
>  Murat> buildroot complexity if only used by jpeg-turbo. When we see
>  Murat> that there are more packages like this, we have to add generic
>  Murat> PROVIDES mechanism.
>
>  Murat> jpeg-turbo's performance gain depends to type of images you're
>  Murat> working on too.  We tested it on mips and arm platform (yes, it
>  Murat> make difference on mips too) and it is %30-%50 times faster than
>  Murat> libjpeg (I don't have the exact results now).  It is a big
>  Murat> difference when you have to make lots of jpeg decompression in
>  Murat> your program.
>
> Is there any reason to NOT use jpeg-turbo? Isn't it source level
> compatible with the "normal" libjpeg?
>
> --
> Bye, Peter Korsgaard
>



-- 
Murat Demirten
Genel M?d?r
http://www.yh.com.tr
(212) 292 04 46 - 113
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120604/c47b6958/attachment.html>

[Buildroot] [PATCH] jpeg-turbo: new package

[Murat Demirten]

Signed-off-by: Murat Demirten <mdemirten@yh.com.tr>
---
 package/Config.in                |    1 +
 package/jpeg-turbo/Config.in     |   26 ++++++++++++++++++++++++++
 package/jpeg-turbo/jpeg-turbo.mk |   22 ++++++++++++++++++++++
 3 files changed, 49 insertions(+), 0 deletions(-)
 create mode 100644 package/jpeg-turbo/Config.in
 create mode 100644 package/jpeg-turbo/jpeg-turbo.mk

diff --git a/package/Config.in b/package/Config.in
index ca8fc96..5a23f66 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -336,6 +336,7 @@ source "package/gtk2-engines/Config.in"
 source "package/gtk2-themes/Config.in"
 source "package/imlib2/Config.in"
 source "package/jpeg/Config.in"
+source "package/jpeg-turbo/Config.in"
 source "package/libart/Config.in"
 source "package/libdmtx/Config.in"
 source "package/libdrm/Config.in"
diff --git a/package/jpeg-turbo/Config.in b/package/jpeg-turbo/Config.in
new file mode 100644
index 0000000..a398079
--- /dev/null
+++ b/package/jpeg-turbo/Config.in
@@ -0,0 +1,26 @@
+config BR2_PACKAGE_JPEG_TURBO
+	bool "jpeg-turbo"
+	help
+	  It is a derivative of libjpeg that uses SIMD instructions
+	  (MMX, SSE2, NEON) to accelerate baseline JPEG compression
+	  and decompression on x86, x86-64, and ARM systems.	  
+
+	  http://libjpeg-turbo.virtualgl.org
+
+choice
+	prompt "libjpeg api version"
+	default BR2_PACKAGE_JPEG_TURBO_APIVERSION_80
+	depends on BR2_PACKAGE_JPEG_TURBO
+	help
+	  Selects libjpeg compatible api version.
+
+config BR2_PACKAGE_JPEG_TURBO_APIVERSION_62
+	bool "62"
+
+config BR2_PACKAGE_JPEG_TURBO_APIVERSION_70
+	bool "70"
+
+config BR2_PACKAGE_JPEG_TURBO_APIVERSION_80
+	bool "80"
+
+endchoice
diff --git a/package/jpeg-turbo/jpeg-turbo.mk b/package/jpeg-turbo/jpeg-turbo.mk
new file mode 100644
index 0000000..54985d9
--- /dev/null
+++ b/package/jpeg-turbo/jpeg-turbo.mk
@@ -0,0 +1,22 @@
+#############################################################
+#
+# jpeg-turbo 
+#
+#############################################################
+JPEG_TURBO_VERSION = 1.2.0
+JPEG_TURBO_SITE = http://$(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/sourceforge/libjpeg-turbo
+JPEG_TURBO_SOURCE = libjpeg-turbo-$(JPEG_TURBO_VERSION).tar.gz
+
+ifeq ($(BR2_PACKAGE_JPEG_TURBO_APIVERSION_80),y)
+	JPEG_TURBO_CONF_ENV += JPEG_LIB_VERSION=80
+endif
+
+ifeq ($(BR2_PACKAGE_JPEG_TURBO_APIVERSION_70),y)
+	JPEG_TURBO_CONF_ENV += JPEG_LIB_VERSION=70
+endif
+
+ifeq ($(BR2_PACKAGE_JPEG_TURBO_APIVERSION_62),y)
+	JPEG_TURBO_CONF_ENV += JPEG_LIB_VERSION=62
+endif
+
+$(eval $(call AUTOTARGETS))
-- 
1.7.5.4