Allow third_party deps to use res/values/layout instead of res/values/layout-v17

Allow third_party deps to use res/values/layout instead of res/values/layout-v17

But still enforce that no attribute mappings need to occur in this case

This applies to adding leakcanary

BUG=

Committed: https://crrev.com/200f55fd3db687d70d351d929ad0470c84be3837
Cr-Commit-Position: refs/heads/master@{#342178}

[agrieve, 2015-07-28 20:10:04]

agrieve@chromium.org changed reviewers:
+ cjhopman@chromium.org

[cjhopman, 2015-07-29 00:44:15]

https://codereview.chromium.org/1261113003/diff/1/build/android/gyp/generate_...
File build/android/gyp/generate_v14_compatible_resources.py (right):

https://codereview.chromium.org/1261113003/diff/1/build/android/gyp/generate_...
build/android/gyp/generate_v14_compatible_resources.py:117: if not 'third_party'
in input_dir or (
I'm not a big fan of this sort of hidden special case based on the directory.

Supporting passing in an extra arg is kind of a pain, can we just skip
generating v14 resources for such a target?

This change will allow a style file that contains the bad
paddingStart/paddingEnd in third_party (paddingStart/End aren't deprecated but
do cause crashes).

We could here make the check more explicit, the only thing we don't want to
allow is a style file in this directory that contains paddingStart/paddingEnd
(or contains deprecated stuff).

[agrieve, 2015-07-29 01:55:01]

https://codereview.chromium.org/1261113003/diff/1/build/android/gyp/generate_...
File build/android/gyp/generate_v14_compatible_resources.py (right):

https://codereview.chromium.org/1261113003/diff/1/build/android/gyp/generate_...
build/android/gyp/generate_v14_compatible_resources.py:117: if not 'third_party'
in input_dir or (
On 2015/07/29 00:44:15, cjhopman wrote:
> I'm not a big fan of this sort of hidden special case based on the directory.

The third_party check isn't strictly necessary, but I thought it'd be good to
continue enforcing the convention of putting all styles within values-v17 for
chromium code

> 
> Supporting passing in an extra arg is kind of a pain, can we just skip
> generating v14 resources for such a target?

We do skip it for this target. The call to GenerateV14StyleResourceDom here just
tells us if the processing would be necessary (and fails if so).

> 
> This change will allow a style file that contains the bad
> paddingStart/paddingEnd in third_party (paddingStart/End aren't deprecated but
> do cause crashes).

Whoops. That wasn't my intention. I've updated the comment and taken out the
assert param.

> 
> We could here make the check more explicit, the only thing we don't want to
> allow is a style file in this directory that contains paddingStart/paddingEnd
> (or contains deprecated stuff).

[agrieve, 2015-07-31 15:50:39]

On 2015/07/29 01:55:01, agrieve wrote:
>
https://codereview.chromium.org/1261113003/diff/1/build/android/gyp/generate_...
> File build/android/gyp/generate_v14_compatible_resources.py (right):
> 
>
https://codereview.chromium.org/1261113003/diff/1/build/android/gyp/generate_...
> build/android/gyp/generate_v14_compatible_resources.py:117: if not
'third_party'
> in input_dir or (
> On 2015/07/29 00:44:15, cjhopman wrote:
> > I'm not a big fan of this sort of hidden special case based on the
directory.
> 
> The third_party check isn't strictly necessary, but I thought it'd be good to
> continue enforcing the convention of putting all styles within values-v17 for
> chromium code
> 
> > 
> > Supporting passing in an extra arg is kind of a pain, can we just skip
> > generating v14 resources for such a target?
> 
> We do skip it for this target. The call to GenerateV14StyleResourceDom here
just
> tells us if the processing would be necessary (and fails if so).
> 
> > 
> > This change will allow a style file that contains the bad
> > paddingStart/paddingEnd in third_party (paddingStart/End aren't deprecated
but
> > do cause crashes).
> 
> Whoops. That wasn't my intention. I've updated the comment and taken out the
> assert param.
> 
> > 
> > We could here make the check more explicit, the only thing we don't want to
> > allow is a style file in this directory that contains
paddingStart/paddingEnd
> > (or contains deprecated stuff).

bump

[cjhopman, 2015-08-03 22:59:21]

lgtm

[agrieve, 2015-08-06 17:53:15]

The CQ bit was checked by agrieve@chromium.org

[commit-bot: I haz the power, 2015-08-06 17:54:18]

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

[commit-bot: I haz the power, 2015-08-06 19:29:30]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-08-06 19:30:04]

Patchset 2 (id:??) landed as
https://crrev.com/200f55fd3db687d70d351d929ad0470c84be3837
Cr-Commit-Position: refs/heads/master@{#342178}