Integrates libjpeg-turbo into Chromium (Chromium side)...

build/common.gypi

Index: build/common.gypi
===================================================================
--- build/common.gypi	(revision 67654)
+++ build/common.gypi	(working copy)
@@ -140,6 +140,11 @@
       # Remoting compilation is enabled by default. Set to 0 to disable.
       'remoting%': 1,
 
+      # The relative path from 'src/third_party' to the GYP file of the JPEG

[Mark Mentovai, 2010/11/30 15:06:01]

This doesn’t need to be relative to src/third_party. Since it ends in _path, it
ought to work to just be relative to this file (common.gypi). GYP will figure
the rest out.

[Hironori Bono, 2010/12/03 09:32:16]

Done. Thank you for noticing it. (Such comments are helpful because I'm a GYP
beginner.)

+      # library used by Chromium. To use libjpeg-turbo instead of libjpeg, we
+      # need to change this variable to 'libjpeg_turbo/libjpeg.gyp'.
+      'libjpeg_gyp_path%': 'libjpeg/libjpeg.gyp',
+
       'library%': '<(library)',
 
       # Variable 'component' is for cases where we would like to build some
@@ -169,6 +174,7 @@
     'sysroot%': '<(sysroot)',
     'disable_sse2%': '<(disable_sse2)',
     'remoting%': '<(remoting)',
+    'libjpeg_gyp_path%': '<(libjpeg_gyp_path)',

[Mark Mentovai, 2010/11/30 15:06:01]

It still might be a good idea to have a condition to flip this to libjpeg-turbo
based on a use_libjpeg_turbo variable. I think it’s better to require the user
to set a variable to 1 than to require the user to set it to a specific path.

[Hironori Bono, 2010/12/03 09:32:16]

Done. I have added a 'use_libjpeg_turbo' variable and switch this
'libjpeg_gyp_path' according to the 'use_libjpeg_turbo' value. (I may be missing
something, though.)

     'library%': '<(library)',
     'component%': '<(component)',