media: Move widevine CDM targets to WidevineCdm folder

media: Move widevine CDM targets to WidevineCdm folder

Put Widevine CDM and adapter in WidevineCdm folder in the output
directory instead of in the output directory directly. This will make it
easier for us to ship manifest.json file alongside with the CDM. It will
also make it easier for use to bundle the CDM on Windows and Mac.

BUG=582622
TEST=Unit tests still pass. Manually tested on Linux.

Committed: https://crrev.com/3569f3d0f45b847990522f1655fb324c55dca887
Cr-Commit-Position: refs/heads/master@{#393672}

[xhwang, 2016-05-06 06:17:09]

Description was changed from

==========
media: Move widevine CDM targets to WidevinceCdm folder.

Put Widevine CDM and adapter in WidevineCdm folder in the output
directory instead of in the output directory directly. This will make it
easier for us to ship manifest.json file alongside with the CDM. It will
also make it easier for use to bundle the CDM on Windows and Mac.

BUG=582622
TEST=Unit tests still pass. Manually tested on Linux.
==========

to

==========
media: Move widevine CDM targets to WidevinceCdm folder

Put Widevine CDM and adapter in WidevineCdm folder in the output
directory instead of in the output directory directly. This will make it
easier for us to ship manifest.json file alongside with the CDM. It will
also make it easier for use to bundle the CDM on Windows and Mac.

BUG=582622
TEST=Unit tests still pass. Manually tested on Linux.
==========

[xhwang, 2016-05-06 16:53:09]

xhwang@chromium.org changed reviewers:
+ ddorwin@chromium.org

[xhwang, 2016-05-06 16:53:10]

CCing waffles@.

This CL only change the current folder structure and is not adding manifest.json
nor bundling the CDM on Win/Mac.

The final folder location is TBD (see discussion in waffles' CL
https://chromiumcodereview.appspot.com/1937683002/), but the current CL should
work well with waffles' current CL.

I tested on Windows official build (with mini_installer) and it's working well.
I need to figure out how to test on Linux (with installer) and Mac.

Otherwise PTAL

[ddorwin, 2016-05-06 22:23:48]

LGTM % comments.

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/BUILD.gn
File chrome/BUILD.gn (right):

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/BUILD.gn#...
chrome/BUILD.gn:228: data_deps += [
"//third_party/widevine/cdm:widevinecdmadapter" ]
What is the reason for this change? Note that the flash_binaries end up in a
PepperFlash/ directory.

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/browser_t...
File chrome/browser_tests.isolate (right):

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/browser_t...
chrome/browser_tests.isolate:38: '<(PRODUCT_DIR)/libclearkeycdm.so',
To ensure ECK is as similar as possible to production CDMs, shouldn't it also be
in a subdirectory (with a manifest.json)?

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/chrome_dl...
File chrome/chrome_dll_bundle.gypi (right):

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/chrome_dl...
chrome/chrome_dll_bundle.gypi:135: # This file is used by the component
installer.
This comment is misleading. The important part is the next line.

[xhwang, 2016-05-09 20:58:27]

comments addressed

[xhwang, 2016-05-09 20:59:03]

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/BUILD.gn
File chrome/BUILD.gn (right):

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/BUILD.gn#...
chrome/BUILD.gn:228: data_deps += [
"//third_party/widevine/cdm:widevinecdmadapter" ]
On 2016/05/06 22:23:48, ddorwin wrote:
> What is the reason for this change? Note that the flash_binaries end up in a
> PepperFlash/ directory.

widevinecdmadapter is a shared_library, the current "deps" is causing chrome
binary to depend on widevinecdmadapter at run time, which isn't desired. Also,
after https://codereview.chromium.org/1525773002/, the rpath is not specified by
default for non-component build, so I actually saw an error where chrome cannot
be loaded because widevinecdmadapter can't be find, unless I specify
LD_LIBRARY_PATH.

Since chrome only need the widevinecdmadapter as a plugin, it makes more sense
to specify it as a data_deps.

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/browser_t...
File chrome/browser_tests.isolate (right):

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/browser_t...
chrome/browser_tests.isolate:38: '<(PRODUCT_DIR)/libclearkeycdm.so',
On 2016/05/06 22:23:48, ddorwin wrote:
> To ensure ECK is as similar as possible to production CDMs, shouldn't it also
be
> in a subdirectory (with a manifest.json)?

Done for the subdirectory.

Currently we are registering the clear key cdm in commandline, so we can't
really use manifest.json. In the future when we use a command flag to enable
clear key cdm, we would be able to use a manifest.json.

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/chrome_dl...
File chrome/chrome_dll_bundle.gypi (right):

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/chrome_dl...
chrome/chrome_dll_bundle.gypi:135: # This file is used by the component
installer.
On 2016/05/06 22:23:48, ddorwin wrote:
> This comment is misleading. The important part is the next line.

Updated.

[ddorwin, 2016-05-09 23:12:56]

LGTM with comment and question.

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/BUILD.gn
File chrome/BUILD.gn (right):

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/BUILD.gn#...
chrome/BUILD.gn:228: data_deps += [
"//third_party/widevine/cdm:widevinecdmadapter" ]
On 2016/05/09 20:59:02, xhwang wrote:
> On 2016/05/06 22:23:48, ddorwin wrote:
> > What is the reason for this change? Note that the flash_binaries end up in a
> > PepperFlash/ directory.
> 
> widevinecdmadapter is a shared_library, the current "deps" is causing chrome
> binary to depend on widevinecdmadapter at run time, which isn't desired. Also,
> after https://codereview.chromium.org/1525773002/, the rpath is not specified
by
> default for non-component build, so I actually saw an error where chrome
cannot
> be loaded because widevinecdmadapter can't be find, unless I specify
> LD_LIBRARY_PATH.
> 
> Since chrome only need the widevinecdmadapter as a plugin, it makes more sense
> to specify it as a data_deps.

Thanks. I wonder whether the flapper_binaries should also be data_deps instead.
Perhaps something to ask the GN/Flash people.

https://chromiumcodereview.appspot.com/1957643002/diff/40001/third_party/wide...
File third_party/widevine/cdm/BUILD.gn (right):

https://chromiumcodereview.appspot.com/1957643002/diff/40001/third_party/wide...
third_party/widevine/cdm/BUILD.gn:79: shared_library("widevinecdm") {
Where does the stub get output now that you removed output_dir? Don't we need it
to end up there, or is that not necessary since this is just to build the
adapter? Do any tests expect it to work?

[xhwang, 2016-05-09 23:50:05]

Comments only. I'll upload a new PS shortly.

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/BUILD.gn
File chrome/BUILD.gn (right):

https://chromiumcodereview.appspot.com/1957643002/diff/20001/chrome/BUILD.gn#...
chrome/BUILD.gn:228: data_deps += [
"//third_party/widevine/cdm:widevinecdmadapter" ]
On 2016/05/09 23:12:56, ddorwin wrote:
> On 2016/05/09 20:59:02, xhwang wrote:
> > On 2016/05/06 22:23:48, ddorwin wrote:
> > > What is the reason for this change? Note that the flash_binaries end up in
a
> > > PepperFlash/ directory.
> > 
> > widevinecdmadapter is a shared_library, the current "deps" is causing chrome
> > binary to depend on widevinecdmadapter at run time, which isn't desired.
Also,
> > after https://codereview.chromium.org/1525773002/, the rpath is not
specified
> by
> > default for non-component build, so I actually saw an error where chrome
> cannot
> > be loaded because widevinecdmadapter can't be find, unless I specify
> > LD_LIBRARY_PATH.
> > 
> > Since chrome only need the widevinecdmadapter as a plugin, it makes more
sense
> > to specify it as a data_deps.
> 
> Thanks. I wonder whether the flapper_binaries should also be data_deps
instead.
> Perhaps something to ask the GN/Flash people.

flapper_binaries is "copy" action [1], which will not force dependants to link
to it [2]. But I agree data_deps is probably more appropriate.

[1]
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/adobe/...

[2]
https://chromium.googlesource.com/chromium/src/+/master/tools/gn/docs/referen...

  Executables, shared libraries, and complete static libraries will
  link all propagated targets and stop propagation. Actions and copy
  steps also stop propagation, allowing them to take a library as an
  input but not force dependants to link to it.

https://chromiumcodereview.appspot.com/1957643002/diff/40001/third_party/wide...
File third_party/widevine/cdm/BUILD.gn (right):

https://chromiumcodereview.appspot.com/1957643002/diff/40001/third_party/wide...
third_party/widevine/cdm/BUILD.gn:79: shared_library("widevinecdm") {
On 2016/05/09 23:12:56, ddorwin wrote:
> Where does the stub get output now that you removed output_dir? Don't we need
it
> to end up there, or is that not necessary since this is just to build the
> adapter? Do any tests expect it to work?

oops, that's clearly a rebase error. I'll revert the change here. Thanks for
catching that.

[xhwang, 2016-05-10 05:24:20]

Patchset #6 (id:100001) has been deleted

[xhwang, 2016-05-10 05:24:26]

Patchset #5 (id:80001) has been deleted

[xhwang, 2016-05-10 05:24:34]

Patchset #4 (id:60001) has been deleted

[xhwang, 2016-05-10 07:22:05]

The CQ bit was checked by xhwang@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-10 07:22:19]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1957643002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1957643002/120001

[commit-bot: I haz the power, 2016-05-10 08:47:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-10 08:47:30]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[xhwang, 2016-05-12 07:33:19]

xhwang@chromium.org changed reviewers:
+ gab@chromium.org

[xhwang, 2016-05-12 07:40:42]

xhwang@chromium.org changed reviewers:
+ thestig@chromium.org

[xhwang, 2016-05-12 07:47:31]

xhwang@chromium.org changed reviewers:
- gab@chromium.org

[xhwang, 2016-05-12 07:48:34]

thestig: Please OWNERS review chrome/ changes. Let me know if I should find
different OWNERS for win/mac specific changes.

[Lei Zhang, 2016-05-12 16:56:58]

Is "WidevinceCdm" a thing or a typo?

[xhwang, 2016-05-12 16:58:23]

Description was changed from

==========
media: Move widevine CDM targets to WidevinceCdm folder

Put Widevine CDM and adapter in WidevineCdm folder in the output
directory instead of in the output directory directly. This will make it
easier for us to ship manifest.json file alongside with the CDM. It will
also make it easier for use to bundle the CDM on Windows and Mac.

BUG=582622
TEST=Unit tests still pass. Manually tested on Linux.
==========

to

==========
media: Move widevine CDM targets to WidevineCdm folder

Put Widevine CDM and adapter in WidevineCdm folder in the output
directory instead of in the output directory directly. This will make it
easier for us to ship manifest.json file alongside with the CDM. It will
also make it easier for use to bundle the CDM on Windows and Mac.

BUG=582622
TEST=Unit tests still pass. Manually tested on Linux.
==========

[xhwang, 2016-05-12 17:00:39]

On 2016/05/12 16:56:58, Lei Zhang wrote:
> Is "WidevinceCdm" a thing or a typo?

Good catch. It's a typo. I fixed the title.

For this CL, WidevineCdm is a new folder where we'll put our CDM adapter (and
CDM on linux/chromeos) in. In later CLs, we'll also put manifest.json in this
folder. A separate folder is also required to supported bundled components:
https://chromiumcodereview.appspot.com/1937683002/

[Lei Zhang, 2016-05-12 17:22:03]

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser/...
File chrome/browser/media/encrypted_media_browsertest.cc (right):

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser/...
chrome/browser/media/encrypted_media_browsertest.cc:281: // The CDM adatper
should be located in |adapter_base_dir| in DIR_MODULE. If
typo

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser/...
chrome/browser/media/encrypted_media_browsertest.cc:282: // |adapter_base_dir|
is empty, then the adapter should be located in
Does the |adapter_base_dir| case still apply?

[Robert Sesek, 2016-05-12 20:13:20]

rsesek@chromium.org changed reviewers:
+ rsesek@chromium.org

[Robert Sesek, 2016-05-12 20:13:21]

The failures on mac_chromium_rel_ng are legitimate, so I don't think this change
is ready yet.

[ddorwin, 2016-05-12 20:59:53]

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser/...
File chrome/browser/media/encrypted_media_supported_types_browsertest.cc
(right):

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser/...
chrome/browser/media/encrypted_media_supported_types_browsertest.cc:313: // but
not the other codecs we expect. http://crbug.com/586634
The old bug provides information about the problem and is useful for that
purpose. Are you sure the new bug will actually fix this?

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser_...
File chrome/browser_tests.isolate (right):

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser_...
chrome/browser_tests.isolate:188:
'<(PRODUCT_DIR)/ClearKeyCdm/libclearkeycdm.dylib',
reorder now

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser_...
chrome/browser_tests.isolate:208: '<(PRODUCT_DIR)/ClearKeyCdm/clearkeycdm.dll',
Should directories comes first?

[xhwang, 2016-05-12 21:14:14]

On 2016/05/12 20:13:21, Robert Sesek wrote:
> The failures on mac_chromium_rel_ng are legitimate, so I don't think this
change
> is ready yet.

Yes, the library path for media_unittests is broken now. I'll fix that and then
address other comments.

[xhwang, 2016-05-13 02:43:35]

The CQ bit was checked by xhwang@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-13 02:43:42]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1957643002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1957643002/180001

[commit-bot: I haz the power, 2016-05-13 04:20:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-13 04:20:57]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[xhwang, 2016-05-13 16:44:12]

I addressed all existing comments.

The browser_tests is timing out on mac_chromium_rel_ng. Locally I can repro it
but it happens on all browser tests so it doesn't seem to be related to my CL.
rsesek and I are looking into it. 

Meanwhile, PTAL again!

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser/...
File chrome/browser/media/encrypted_media_browsertest.cc (right):

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser/...
chrome/browser/media/encrypted_media_browsertest.cc:281: // The CDM adatper
should be located in |adapter_base_dir| in DIR_MODULE. If
On 2016/05/12 17:22:02, Lei Zhang wrote:
> typo

Done.

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser/...
chrome/browser/media/encrypted_media_browsertest.cc:282: // |adapter_base_dir|
is empty, then the adapter should be located in
On 2016/05/12 17:22:02, Lei Zhang wrote:
> Does the |adapter_base_dir| case still apply?

Removed.

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser/...
File chrome/browser/media/encrypted_media_supported_types_browsertest.cc
(right):

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser/...
chrome/browser/media/encrypted_media_supported_types_browsertest.cc:313: // but
not the other codecs we expect. http://crbug.com/586634
On 2016/05/12 20:59:53, ddorwin wrote:
> The old bug provides information about the problem and is useful for that
> purpose. Are you sure the new bug will actually fix this?

I am not sure. Reverted this change and we'll revisit this later.

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser_...
File chrome/browser_tests.isolate (right):

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser_...
chrome/browser_tests.isolate:188:
'<(PRODUCT_DIR)/ClearKeyCdm/libclearkeycdm.dylib',
On 2016/05/12 20:59:53, ddorwin wrote:
> reorder now

Done.

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser_...
chrome/browser_tests.isolate:208: '<(PRODUCT_DIR)/ClearKeyCdm/clearkeycdm.dll',
On 2016/05/12 20:59:53, ddorwin wrote:
> Should directories comes first?

It seems not the case, see line 85 for example.

[xhwang, 2016-05-13 18:13:52]

For the record:

The previous failure on mac_chromium_rel_ng seems to be a bot issue according to
rsesek@.

The local failure was because I have "is_chrome_branded=true", where mac gn
build doesn't fully work with Chrome branding build yet. After I drop
"is_chrome_branded=true" the test is passing locally.

[Lei Zhang, 2016-05-13 20:24:56]

lgtm

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser_...
File chrome/browser_tests.isolate (right):

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser_...
chrome/browser_tests.isolate:208: '<(PRODUCT_DIR)/ClearKeyCdm/clearkeycdm.dll',
On 2016/05/13 16:44:12, xhwang wrote:
> On 2016/05/12 20:59:53, ddorwin wrote:
> > Should directories comes first?
> 
> It seems not the case, see line 85 for example.

It should if you do ASCII sort.

[xhwang, 2016-05-13 20:58:34]

rsesek: Please take a look at mac changes. Thanks!

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser_...
File chrome/browser_tests.isolate (right):

https://chromiumcodereview.appspot.com/1957643002/diff/160001/chrome/browser_...
chrome/browser_tests.isolate:208: '<(PRODUCT_DIR)/ClearKeyCdm/clearkeycdm.dll',
On 2016/05/13 20:24:56, Lei Zhang wrote:
> On 2016/05/13 16:44:12, xhwang wrote:
> > On 2016/05/12 20:59:53, ddorwin wrote:
> > > Should directories comes first?
> > 
> > It seems not the case, see line 85 for example.
> 
> It should if you do ASCII sort.

Hmm, I am not sure whether we do strict ASCII sort in gyp/gn files, or just
follow alphabetical orders?

[Robert Sesek, 2016-05-13 22:32:43]

https://codereview.chromium.org/1957643002/diff/220001/chrome/browser/media/e...
File chrome/browser/media/encrypted_media_supported_types_browsertest.cc
(right):

https://codereview.chromium.org/1957643002/diff/220001/chrome/browser/media/e...
chrome/browser/media/encrypted_media_supported_types_browsertest.cc:337:
RegisterPepperCdm(command_line, "WidevineCdm",
This can't use kWidevineCdmBaseDirectory ?

https://codereview.chromium.org/1957643002/diff/220001/third_party/widevine/c...
File third_party/widevine/cdm/BUILD.gn (right):

https://codereview.chromium.org/1957643002/diff/220001/third_party/widevine/c...
third_party/widevine/cdm/BUILD.gn:142: ldflags = [
rebase_path("$root_out_dir/WidevineCdm/libwidevinecdm.dylib",
This is probably wrong, but I'll deal with it later.

[xhwang, 2016-05-13 22:45:37]

https://codereview.chromium.org/1957643002/diff/220001/chrome/browser/media/e...
File chrome/browser/media/encrypted_media_supported_types_browsertest.cc
(right):

https://codereview.chromium.org/1957643002/diff/220001/chrome/browser/media/e...
chrome/browser/media/encrypted_media_supported_types_browsertest.cc:337:
RegisterPepperCdm(command_line, "WidevineCdm",
On 2016/05/13 22:32:42, Robert Sesek wrote:
> This can't use kWidevineCdmBaseDirectory ?

kWidevineCdmBaseDirectory is only available when WIDEVINE_CDM_AVAILABLE is
defined. The purpose of this test is that no matter  WIDEVINE_CDM_AVAILABLE is
true or false, registering the CDM with a wrong path or file name will always
fail.

https://codereview.chromium.org/1957643002/diff/220001/third_party/widevine/c...
File third_party/widevine/cdm/BUILD.gn (right):

https://codereview.chromium.org/1957643002/diff/220001/third_party/widevine/c...
third_party/widevine/cdm/BUILD.gn:142: ldflags = [
rebase_path("$root_out_dir/WidevineCdm/libwidevinecdm.dylib",
On 2016/05/13 22:32:42, Robert Sesek wrote:
> This is probably wrong, but I'll deal with it later.

Acknowledged.

[Robert Sesek, 2016-05-13 22:54:08]

lgtm

[xhwang, 2016-05-13 22:57:10]

The CQ bit was checked by xhwang@chromium.org

[xhwang, 2016-05-13 22:57:10]

The patchset sent to the CQ was uploaded after l-g-t-m from ddorwin@chromium.org
Link to the patchset:
https://chromiumcodereview.appspot.com/1957643002/#ps220001 (title:
"@loader_path/.")

[commit-bot: I haz the power, 2016-05-13 22:57:59]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1957643002/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1957643002/220001

[commit-bot: I haz the power, 2016-05-13 23:03:25]

Description was changed from

==========
media: Move widevine CDM targets to WidevineCdm folder

Put Widevine CDM and adapter in WidevineCdm folder in the output
directory instead of in the output directory directly. This will make it
easier for us to ship manifest.json file alongside with the CDM. It will
also make it easier for use to bundle the CDM on Windows and Mac.

BUG=582622
TEST=Unit tests still pass. Manually tested on Linux.
==========

to

==========
media: Move widevine CDM targets to WidevineCdm folder

Put Widevine CDM and adapter in WidevineCdm folder in the output
directory instead of in the output directory directly. This will make it
easier for us to ship manifest.json file alongside with the CDM. It will
also make it easier for use to bundle the CDM on Windows and Mac.

BUG=582622
TEST=Unit tests still pass. Manually tested on Linux.
==========

[commit-bot: I haz the power, 2016-05-13 23:03:28]

Committed patchset #9 (id:220001)

[commit-bot: I haz the power, 2016-05-13 23:04:56]

Description was changed from

==========
media: Move widevine CDM targets to WidevineCdm folder

Put Widevine CDM and adapter in WidevineCdm folder in the output
directory instead of in the output directory directly. This will make it
easier for us to ship manifest.json file alongside with the CDM. It will
also make it easier for use to bundle the CDM on Windows and Mac.

BUG=582622
TEST=Unit tests still pass. Manually tested on Linux.
==========

to

==========
media: Move widevine CDM targets to WidevineCdm folder

Put Widevine CDM and adapter in WidevineCdm folder in the output
directory instead of in the output directory directly. This will make it
easier for us to ship manifest.json file alongside with the CDM. It will
also make it easier for use to bundle the CDM on Windows and Mac.

BUG=582622
TEST=Unit tests still pass. Manually tested on Linux.

Committed: https://crrev.com/3569f3d0f45b847990522f1655fb324c55dca887
Cr-Commit-Position: refs/heads/master@{#393672}
==========

[commit-bot: I haz the power, 2016-05-13 23:04:58]

Patchset 9 (id:??) landed as
https://crrev.com/3569f3d0f45b847990522f1655fb324c55dca887
Cr-Commit-Position: refs/heads/master@{#393672}

[stgao, 2016-05-14 06:30:17]

stgao@chromium.org changed reviewers:
+ stgao@chromium.org

[stgao, 2016-05-14 06:30:18]

FYI: Findit's try-jobs identified this CL as the culprit to break compile on Mac

https://findit-for-me.appspot.com/waterfall/build-failure?url=https%3A%2F%2Fb...

https://findit-for-me.appspot.com/waterfall/build-failure?url=https%3A%2F%2Fb...

[xhwang, 2016-05-14 06:36:11]

On 2016/05/14 06:30:18, stgao wrote:
> FYI: Findit's try-jobs identified this CL as the culprit to break compile on
Mac
> 
>
https://findit-for-me.appspot.com/waterfall/build-failure?url=https%3A%2F%2Fb...
> 
>
https://findit-for-me.appspot.com/waterfall/build-failure?url=https%3A%2F%2Fb...

I'll take a look

[xhwang, 2016-05-14 07:16:10]

Description was changed from

==========
media: Move widevine CDM targets to WidevineCdm folder

Put Widevine CDM and adapter in WidevineCdm folder in the output
directory instead of in the output directory directly. This will make it
easier for us to ship manifest.json file alongside with the CDM. It will
also make it easier for use to bundle the CDM on Windows and Mac.

BUG=582622
TEST=Unit tests still pass. Manually tested on Linux.

Committed: https://crrev.com/3569f3d0f45b847990522f1655fb324c55dca887
Cr-Commit-Position: refs/heads/master@{#393672}
==========

to

==========
media: Move widevine CDM targets to WidevineCdm folder

Put Widevine CDM and adapter in WidevineCdm folder in the output
directory instead of in the output directory directly. This will make it
easier for us to ship manifest.json file alongside with the CDM. It will
also make it easier for use to bundle the CDM on Windows and Mac.

BUG=582622
TEST=Unit tests still pass. Manually tested on Linux.

Committed: https://crrev.com/3569f3d0f45b847990522f1655fb324c55dca887
Cr-Commit-Position: refs/heads/master@{#393672}
==========

[xhwang, 2016-05-14 07:16:10]

xhwang@chromium.org changed reviewers:
+ mark@chromium.org, thakis@chromium.org

[xhwang, 2016-05-14 07:20:57]

On 2016/05/14 06:36:11, xhwang wrote:
> On 2016/05/14 06:30:18, stgao wrote:
> > FYI: Findit's try-jobs identified this CL as the culprit to break compile on
> Mac
> > 
> >
>
https://findit-for-me.appspot.com/waterfall/build-failure?url=https%3A%2F%2Fb...
> > 
> >
>
https://findit-for-me.appspot.com/waterfall/build-failure?url=https%3A%2F%2Fb...
> 
> I'll take a look

+mark and thakis who may know what's the best solution.

The built binary is located at
out/Release/WidevineCdm/widevinecdmadapter.plugin. Then strip_from_xcode is
calling:

exec "$(dirname ${0})/strip_save_dsym" "${FLAGS[@]}"
"${BUILT_PRODUCTS_DIR}/${EXECUTABLE_PATH}"

where

BUILT_PRODUCTS_DIR=/b/build/slave/google-chrome-rel-mac/build/src/out/Release
EXECUTABLE_PATH=widevinecdmadapter.plugin

So it's trying to look for the binary at out/Release/widevinecdmadapter.plugin,
and it's obviously missing the new WidevineCdm folder.

I don't really know how to fix this. Still looking

[Ken Rockot(use gerrit already), 2016-05-15 00:38:26]

rockot@chromium.org changed reviewers:
+ rockot@chromium.org

[Ken Rockot(use gerrit already), 2016-05-15 00:38:27]

Lots of broken stuff. Can this be reverted?

https://build.chromium.org/p/chromium/builders/Mac
https://build.chromium.org/p/chromium.linux/builders/Linux%20Tests%20%28dbg%2...

[Ken Rockot(use gerrit already), 2016-05-15 00:52:58]

A revert of this CL (patchset #9 id:220001) has been created in
https://codereview.chromium.org/1978123002/ by rockot@chromium.org.

The reason for reverting is: Multiple problems. Compile failures on Mac and
browser_tests failures on Linux.

Mac failure logs:

[12124/32437] SOLINK ClearKeyCdm/libclearkeycdm.dylib, POSTBUILDS
FAILED: ClearKeyCdm/libclearkeycdm.dylib ClearKeyCdm/libclearkeycdm.dylib.TOC 
if [ ! -e ClearKeyCdm/libclearkeycdm.dylib -o ! -e
ClearKeyCdm/libclearkeycdm.dylib.TOC ] || otool -l
ClearKeyCdm/libclearkeycdm.dylib | grep -q LC_REEXPORT_DYLIB ; then
/b/build/slave/cache/cipd/goma/gomacc
../../third_party/llvm-build/Release+Asserts/bin/clang++ -shared
-Wl,-search_paths_first -Wl,-dead_strip -mmacosx-version-min=10.7 -isysroot
/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk
-arch x86_64 -L. -install_name @rpath/libclearkeycdm.dylib -stdlib=libc++ -o
ClearKeyCdm/libclearkeycdm.dylib @ClearKeyCdm/libclearkeycdm.dylib.rsp &&
(export BUILT_FRAMEWORKS_DIR=/b/build/slave/Mac/build/src/out/Release; export
BUILT_PRODUCTS_DIR=/b/build/slave/Mac/build/src/out/Release; export
CONFIGURATION=Release; export DYLIB_INSTALL_NAME_BASE=@rpath; export
EXECUTABLE_NAME=libclearkeycdm.dylib; export
EXECUTABLE_PATH=libclearkeycdm.dylib; export
FULL_PRODUCT_NAME=libclearkeycdm.dylib; export
LD_DYLIB_INSTALL_NAME=@rpath/libclearkeycdm.dylib; export MACH_O_TYPE=mh_dylib;
export PRODUCT_NAME=clearkeycdm; export
PRODUCT_TYPE=com.apple.product-type.library.dynamic; export
SDKROOT=/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk;
export SRCROOT=/b/build/slave/Mac/build/src/out/Release/../../media; export
SOURCE_ROOT="${SRCROOT}"; export
TARGET_BUILD_DIR=/b/build/slave/Mac/build/src/out/Release; export
TEMP_DIR="${TMPDIR}"; export XCODE_VERSION_ACTUAL=0511; (cd ../../media &&
../build/mac/strip_from_xcode); G=$?; ((exit $G) || rm -rf
ClearKeyCdm/libclearkeycdm.dylib) && exit $G) && { otool -l
ClearKeyCdm/libclearkeycdm.dylib | grep LC_ID_DYLIB -A 5; nm -gP
ClearKeyCdm/libclearkeycdm.dylib | cut -f1-2 -d' ' | grep -v U$; true; } >
ClearKeyCdm/libclearkeycdm.dylib.TOC; else /b/build/slave/cache/cipd/goma/gomacc
../../third_party/llvm-build/Release+Asserts/bin/clang++ -shared
-Wl,-search_paths_first -Wl,-dead_strip -mmacosx-version-min=10.7 -isysroot
/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk
-arch x86_64 -L. -install_name @rpath/libclearkeycdm.dylib -stdlib=libc++ -o
ClearKeyCdm/libclearkeycdm.dylib @ClearKeyCdm/libclearkeycdm.dylib.rsp &&
(export BUILT_FRAMEWORKS_DIR=/b/build/slave/Mac/build/src/out/Release; export
BUILT_PRODUCTS_DIR=/b/build/slave/Mac/build/src/out/Release; export
CONFIGURATION=Release; export DYLIB_INSTALL_NAME_BASE=@rpath; export
EXECUTABLE_NAME=libclearkeycdm.dylib; export
EXECUTABLE_PATH=libclearkeycdm.dylib; export
FULL_PRODUCT_NAME=libclearkeycdm.dylib; export
LD_DYLIB_INSTALL_NAME=@rpath/libclearkeycdm.dylib; export MACH_O_TYPE=mh_dylib;
export PRODUCT_NAME=clearkeycdm; export
PRODUCT_TYPE=com.apple.product-type.library.dynamic; export
SDKROOT=/Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk;
export SRCROOT=/b/build/slave/Mac/build/src/out/Release/../../media; export
SOURCE_ROOT="${SRCROOT}"; export
TARGET_BUILD_DIR=/b/build/slave/Mac/build/src/out/Release; export
TEMP_DIR="${TMPDIR}"; export XCODE_VERSION_ACTUAL=0511; (cd ../../media &&
../build/mac/strip_from_xcode); G=$?; ((exit $G) || rm -rf
ClearKeyCdm/libclearkeycdm.dylib) && exit $G) && { otool -l
ClearKeyCdm/libclearkeycdm.dylib | grep LC_ID_DYLIB -A 5; nm -gP
ClearKeyCdm/libclearkeycdm.dylib | cut -f1-2 -d' ' | grep -v U$; true; } >
ClearKeyCdm/libclearkeycdm.dylib.tmp && if ! cmp -s
ClearKeyCdm/libclearkeycdm.dylib.tmp ClearKeyCdm/libclearkeycdm.dylib.TOC; then
mv ClearKeyCdm/libclearkeycdm.dylib.tmp ClearKeyCdm/libclearkeycdm.dylib.TOC ;
fi; fi
Traceback (most recent call last):
  File "/b/build/slave/Mac/build/src/media/../build/mac/strip_save_dsym", line
335, in <module>
    sys.exit(main(sys.argv))
  File "/b/build/slave/Mac/build/src/media/../build/mac/strip_save_dsym", line
329, in main
    if not strip_and_make_fake_dsym(macho):
  File "/b/build/slave/Mac/build/src/media/../build/mac/strip_save_dsym", line
263, in strip_and_make_fake_dsym
    macho_stat = os.stat(macho)
OSError: [Errno 2] No such file or directory:
'/b/build/slave/Mac/build/src/out/Release/libclearkeycdm.dylib'



Failing Linux (dbg) tests:

MSE_ExternalClearKey/EncryptedMediaTest.Playback_Multiple_VideoAudio_WebM/0
ECKEncryptedMediaTest.LoadUnknownSession
SRC_ExternalClearKey/EncryptedMediaTest.Playback_AudioOnly_WebM/0
MSE_ExternalClearKeyDecryptOnly/EncryptedMediaTest.Playback_VideoClearAudio_WebM/0
PepperContentSettingsSpecialCasesTest.Baseline
SRC_ExternalClearKey/EncryptedMediaTest.Playback_Multiple_VideoAudio_WebM/0
SRC_ExternalClearKey/EncryptedMediaTest.Playback_VideoAudio_WebM_Opus/0
MSE_ExternalClearKey/EncryptedMediaTest.InvalidResponseKeyError/0
MSE_ExternalClearKeyDecryptOnly/EncryptedMediaTest.Playback_VideoClearAudio_WebM_Opus/0
SRC_ExternalClearKey/EncryptedMediaTest.Playback_VideoClearAudio_WebM_Opus/0
ECKEncryptedMediaTest.LoadLoadableSession
MSE_ExternalClearKeyDecryptOnly/EncryptedMediaTest.ConfigChangeVideo/0
MSE_ExternalClearKey/EncryptedMediaTest.Playback_AudioOnly_WebM/0
MSE_ExternalClearKey/EncryptedMediaTest.Playback_VideoClearAudio_WebM_Opus/0
MSE_ExternalClearKey/EncryptedMediaTest.Playback_VideoOnly_WebM/0
MSE_ExternalClearKeyDecryptOnly/EncryptedMediaTest.FrameSizeChangeVideo/0
SRC_ExternalClearKey/EncryptedMediaTest.InvalidResponseKeyError/0
ECKEncryptedMediaTest.CDMCrashDuringDecode
MSE_ExternalClearKeyDecryptOnly/EncryptedMediaTest.Playback_VideoAudio_WebM_Opus/0
MSE_ExternalClearKeyDecryptOnly/EncryptedMediaTest.InvalidResponseKeyError/0
SRC_ExternalClearKey/EncryptedMediaTest.Playback_VideoClearAudio_WebM/0
MSE_ExternalClearKeyDecryptOnly/EncryptedMediaTest.Playback_AudioClearVideo_WebM/0
MSE_ExternalClearKeyDecryptOnly/EncryptedMediaTest.Playback_Multiple_VideoAudio_WebM/0
SRC_ExternalClearKey/EncryptedMediaTest.Playback_AudioClearVideo_WebM/0
MSE_ExternalClearKey/EncryptedMediaTest.Playback_VideoAudio_WebM/0
SRC_ExternalClearKey/EncryptedMediaTest.Playback_AudioOnly_WebM_Opus/0
MSE_ExternalClearKeyDecryptOnly/EncryptedMediaTest.Playback_VideoOnly_WebM/0
MSE_ExternalClearKey/EncryptedMediaTest.Playback_AudioClearVideo_WebM/0
SRC_ExternalClearKey/EncryptedMediaTest.Playback_VideoAudio_WebM/0
MSE_ExternalClearKeyDecryptOnly/EncryptedMediaTest.Playback_VideoAudio_WebM/0
MSE_ExternalClearKey/EncryptedMediaTest.Playback_VideoClearAudio_WebM/0
ECKEncryptedMediaTest.CDMExpectedCrash
ECKEncryptedMediaTest.FileIOTest
MSE_ExternalClearKeyDecryptOnly/EncryptedMediaTest.Playback_AudioOnly_WebM/0
MSE_ExternalClearKey/EncryptedMediaTest.Playback_VP9Video_WebM/0
MSE_ExternalClearKey/EncryptedMediaTest.ConfigChangeVideo/0
MSE_ExternalClearKeyDecryptOnly/EncryptedMediaTest.Playback_VP9Video_WebM/0
SRC_ExternalClearKey/EncryptedMediaTest.Playback_VideoOnly_WebM/0
MSE_ExternalClearKey/EncryptedMediaTest.FrameSizeChangeVideo/0
SRC_ExternalClearKey/EncryptedMediaTest.FrameSizeChangeVideo/0
MSE_ExternalClearKey/EncryptedMediaTest.Playback_VideoAudio_WebM_Opus/0
MSE_ExternalClearKeyDecryptOnly/EncryptedMediaTest.Playback_AudioOnly_WebM_Opus/0
SRC_ExternalClearKey/EncryptedMediaTest.Playback_VP9Video_WebM/0
MSE_ExternalClearKey/EncryptedMediaTest.Playback_AudioOnly_WebM_Opus/0.

[xhwang, 2016-05-15 05:15:13]

Thanks for the revert. I'll need help from Mac guru's about the Mac issue. It
looks like the strip command won't work if I specify a different 'product_dir'.

The Linux failure is new to me. Seem like permission related:

[1:1:0514/204349:ERROR:ppapi_thread.cc(301)] Failed to load Pepper module from
/tmp/runS0ZqBJ/out/Debug/ClearKeyCdm/libclearkeycdmadapter.so (error:
/tmp/runS0ZqBJ/out/Debug/ClearKeyCdm/libclearkeycdmadapter.so: cannot open
shared object file: Operation not permitted)

I'll try to see if I can repro.