Add build files for libjpeg-turbo....

Add build files for libjpeg-turbo.
This change adds a GYP file, header files, and a README file used for building libjpeg-turbo. (This GYP file builds libjpeg-turbo only on Windows and Mac since Linux uses the system libjpeg.)

BUG=48789
TEST=build libjpeg-turbo on Windows and Mac.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=66929

[brettw, 2010-11-05 05:52:45]

LGTM, but I'd feel better if a GYP expert gave your new file a quick once-over
since it's totally new and a little more complicated than most. I added Mark.

[Hironori Bono, 2010-11-16 09:10:09]

Greetings Mark,

Would it be possible to give me your comments?

Regards,

Hironori Bono

On 2010/11/05 05:52:45, brettw wrote:
> LGTM, but I'd feel better if a GYP expert gave your new file a quick once-over
> since it's totally new and a little more complicated than most. I added Mark.

[Mark Mentovai, 2010-11-16 14:49:47]

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/READM...
File third_party/libjpeg_turbo/README.chromium (right):

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/READM...
third_party/libjpeg_turbo/README.chromium:16: arise when system libraries
attempt to use our libjpeg.
Also mention google.patch.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
File third_party/libjpeg_turbo/libjpeg.gyp (right):

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:1: # Copyright (c) 2009 The Chromium
Authors. All rights reserved.
2010

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:20: 'shared_generated_dir':
'<(INTERMEDIATE_DIR)/third_party/libjpeg',
1. Why did this need to be split out by platform? Did the
SHARED_INTERMEDIATE_DIR form not work for everyone?

2. The name that this uses for intermediate files on disk should probably be
libjpeg_turbo to match the product name.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:32: 'msvs_guid':
'238CE175-76CE-4A25-A676-69D115885601',
This GUID shows up in a Google search. It’s not globally unique any more.

msvs_guid is optional, just remove it. Same on line 172.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:106: [ 'OS!="win"', {'product_name':
'jpeg'}],
Recommend jpeg_turbo. GYP will figure everything else out, but when we’re using
the turbo variant, we should probably name the output library after it.

On Windows, product_name should be libjpeg_turbo.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:168: # A project that assembles asm files
and creates object files.
If you wanted to, you could just move all of this into the libjpeg target, and
GYP would figure out whether it needed to split it into a separate target when
it produces project files. Up to you.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:174: # Adding platform-dependent source
files.
Add, not adding.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:240: 'inputs': [ '<(nasm_path)', ],
Do any of the asm files include anything else?

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:255: 'message': 'Build
<(RULE_INPUT_PATH).',
Doesn’t seem right—it seems like this should say

'message': 'Building <(RULE_INPUT_ROOT).<(object_suffix)',

Same on 281 and 320.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:261: 'nasm_path': '<!(which nasm)',
Do you know what this expands to at runtime?

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:327: }, {
Put a comment here like

}, {  # else: use_system_libjpeg != 0

[Hironori Bono, 2010-11-19 05:44:34]

Greetings,

Thank you so much for your comments. As noted in a change from fbarchard, this
change now uses yasm instead of nasm and I have changed some of this GYP file so
we can build libjpeg-turbo with yasm. Is it possible to take another look?

Regards,

Hironori Bono

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/READM...
File third_party/libjpeg_turbo/README.chromium (right):

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/READM...
third_party/libjpeg_turbo/README.chromium:16: arise when system libraries
attempt to use our libjpeg.
On 2010/11/16 14:49:52, Mark Mentovai wrote:
> Also mention google.patch.

Done.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
File third_party/libjpeg_turbo/libjpeg.gyp (right):

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:1: # Copyright (c) 2009 The Chromium
Authors. All rights reserved.
On 2010/11/16 14:49:52, Mark Mentovai wrote:
> 2010

Done.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:20: 'shared_generated_dir':
'<(INTERMEDIATE_DIR)/third_party/libjpeg',
On 2010/11/16 14:49:52, Mark Mentovai wrote:
> 1. Why did this need to be split out by platform? Did the
> SHARED_INTERMEDIATE_DIR form not work for everyone?

Unfortunately, make.py (of GYP) causes some problems when a 'sources' list
includes object files. (This is GYP Issue 102.) For an object file in a
'sources' list, the Objectify function (used in the input path for $(OBJS))
replaces SHARED_INTERMEDIATE_DIR with '$(obj).target/$(TARGET)/gen". On the
other hand, the Sourcify function (used as the output paths for custom rules)
replaces it with '$(obj)/gen'. Therefore, we cannot find object files created by
a custom rule. (I wish we can fix Issue 102 so I don't have to use this
workaround.)  
 
> 2. The name that this uses for intermediate files on disk should probably be
> libjpeg_turbo to match the product name.

Done.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:32: 'msvs_guid':
'238CE175-76CE-4A25-A676-69D115885601',
On 2010/11/16 14:49:52, Mark Mentovai wrote:
> This GUID shows up in a Google search. It’s not globally unique any more. 
> msvs_guid is optional, just remove it. Same on line 172.

Done.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:106: [ 'OS!="win"', {'product_name':
'jpeg'}],
On 2010/11/16 14:49:52, Mark Mentovai wrote:
> Recommend jpeg_turbo. GYP will figure everything else out, but when we’re
using
> the turbo variant, we should probably name the output library after it.
> 
> On Windows, product_name should be libjpeg_turbo.

Done.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:168: # A project that assembles asm files
and creates object files.
On 2010/11/16 14:49:52, Mark Mentovai wrote:
> If you wanted to, you could just move all of this into the libjpeg target, and
> GYP would figure out whether it needed to split it into a separate target when
> it produces project files. Up to you.

I would like to keep the current form to keep consistency with ffmpeg.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:174: # Adding platform-dependent source
files.
On 2010/11/16 14:49:52, Mark Mentovai wrote:
> Add, not adding.

Done.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:240: 'inputs': [ '<(nasm_path)', ],
On 2010/11/16 14:49:52, Mark Mentovai wrote:
> Do any of the asm files include anything else?

Fortunately, not. Thank you for noticing it.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:255: 'message': 'Build
<(RULE_INPUT_PATH).',
On 2010/11/16 14:49:52, Mark Mentovai wrote:
> Doesn’t seem right—it seems like this should say
> 
> 'message': 'Building <(RULE_INPUT_ROOT).<(object_suffix)',
> 
> Same on 281 and 320.

Done.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:261: 'nasm_path': '<!(which nasm)',
On 2010/11/16 14:49:52, Mark Mentovai wrote:
> Do you know what this expands to at runtime?

It became "/usr/bin/nasm". By the way, as written in a yasm change from
fbarchard, we now use yasm instead of nasm to build libjpeg-turbo. So, I have
changed all nasm paths with yasm.

http://codereview.chromium.org/4298001/diff/1/third_party/libjpeg_turbo/libjp...
third_party/libjpeg_turbo/libjpeg.gyp:327: }, {
On 2010/11/16 14:49:52, Mark Mentovai wrote:
> Put a comment here like
> 
> }, {  # else: use_system_libjpeg != 0

Done.

[Mark Mentovai, 2010-11-19 17:12:24]

LGTM

http://codereview.chromium.org/4298001/diff/20001/third_party/libjpeg_turbo/l...
File third_party/libjpeg_turbo/libjpeg.gyp (right):

http://codereview.chromium.org/4298001/diff/20001/third_party/libjpeg_turbo/l...
third_party/libjpeg_turbo/libjpeg.gyp:20: # This is a workaround for GYP issue
102.
Thanks for adding this comment.

http://codereview.chromium.org/4298001/diff/20001/third_party/libjpeg_turbo/l...
third_party/libjpeg_turbo/libjpeg.gyp:262: '../yasm/yasm.gyp:yasm#host',
Have you tested this on the Mac? I wasn’t involved with the toolchain stuff and
don’t know much about #host.

[Hironori Bono, 2010-11-22 09:01:37]

http://codereview.chromium.org/4298001/diff/20001/third_party/libjpeg_turbo/l...
File third_party/libjpeg_turbo/libjpeg.gyp (right):

http://codereview.chromium.org/4298001/diff/20001/third_party/libjpeg_turbo/l...
third_party/libjpeg_turbo/libjpeg.gyp:20: # This is a workaround for GYP issue
102.
On 2010/11/19 17:12:25, Mark Mentovai wrote:
> Thanks for adding this comment.

It's not a problem. I should have added this comment.

http://codereview.chromium.org/4298001/diff/20001/third_party/libjpeg_turbo/l...
third_party/libjpeg_turbo/libjpeg.gyp:262: '../yasm/yasm.gyp:yasm#host',
On 2010/11/19 17:12:25, Mark Mentovai wrote:
> Have you tested this on the Mac? I wasn’t involved with the toolchain stuff
and
> don’t know much about #host.

Yes, I have verified we can build libjpeg-turbo with yasm-1.1 on Mac.
(Nevertheless, this change does not improve the performance that Mac Chrome
renders a web page since Mac Chrome uses CoreGraphics to decode JPEG files as
Safari does.)

[Mark Mentovai, 2010-11-22 14:40:36]

hbono@chromium.org wrote:
> Yes, I have verified we can build libjpeg-turbo with yasm-1.1 on Mac.
> (Nevertheless, this change does not improve the performance that Mac
> Chrome renders a web page since Mac Chrome uses CoreGraphics to decode
> JPEG files as Safari does.)

Avi mentioned to me that this changed, although I haven’t verified.

(Not using CG means we lose color correction, and I’m not too thrilled
about that.)