jpeg-turbo: new package

Hello,

Le Sun, 3 Jun 2012 05:57:46 +0300,
Murat Demirten <[email protected]> a ?crit :

package/jpeg-turbo/Config.in line 2

Quoted 5 lines

package/jpeg-turbo/Config.in new file +2 -0

@@ -0,0 +1,26 @@
+config BR2_PACKAGE_JPEG_TURBO
+ bool "jpeg-turbo"

Indentation should be one tab.

package/jpeg-turbo/Config.in line 3

Quoted 1 line

package/jpeg-turbo/Config.in new file +1 -0

+ help

Here as well.

package/jpeg-turbo/Config.in line 8

Quoted 5 lines

package/jpeg-turbo/Config.in new file +5 -0

+   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)

package/jpeg-turbo/Config.in line 11

Quoted 2 lines

package/jpeg-turbo/Config.in new file +2 -0

+choice
+ prompt "libjpeg api version"

Fix indentation everywhere :)

package/jpeg-turbo/Config.in

Quoted 7 lines

package/jpeg-turbo/Config.in new file +6 -1

--- /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

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)

Hi Murat, all,

2012/6/3 Murat Demirten <[email protected]>

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 2 lines

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 ;-)

Quoted 3 lines

(I will send a patch with git send-email, previous one is the result of

a firewall which blocking outgoing smtp and webmail client)

Quoted 2 lines

Again, thx for contributing to BR,

Cheers,

--
Sam

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Murat" == Murat Demirten <[email protected]> writes:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Murat" == Murat Demirten <[email protected]> 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