move protect_file_posix to posix block

move protect_file_posix to posix block

Otherwise, on Windows when 'All' is built the no-op build is broken --
no files are included in the .lib so none is generated, which means on
subsequent builds ninja always reruns that step.

This is currently breaking win_chromium_compile_dbg_ng trybots.

R=pasko@chromium.org, thakis@chromium.org
BUG=424562
Committed: https://crrev.com/a03124d1119077caad658d8a39e59365ca64541d
Cr-Commit-Position: refs/heads/master@{#319119}

[scottmg, 2015-03-04 18:37:35]

scottmg@chromium.org changed reviewers:
+ thakis@chromium.org

[scottmg, 2015-03-04 18:38:55]

+thakis base OWNERS

[Nico, 2015-03-04 18:41:53]

I think this will break the build of
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/chrome_shel...
on mac?

[Nico, 2015-03-04 18:42:35]

(more conservative fix: make the target type none if OS!=posix, static_library
else)

[scottmg, 2015-03-04 18:53:29]

On 2015/03/04 18:41:53, Nico wrote:
> I think this will break the build of
>
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/chrome_shel...
> on mac?

Oh, I thought that was Android only. I'll switch the target type.

[scottmg, 2015-03-04 19:01:46]

On 2015/03/04 18:53:29, scottmg wrote:
> On 2015/03/04 18:41:53, Nico wrote:
> > I think this will break the build of
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/chrome_shel...
> > on mac?
> 
> Oh, I thought that was Android only. I'll switch the target type.

os_posix == OS != win

but 

filename_rules.gypi filters _posix for 'OS=="win" and >(nacl_untrusted_build) ==
0' whatever that means. Sigh.

...

Oh, nacl_untrusted_build is set per-target (I think). So, putting that target in
os_posix == 1 seems the closest to right.

[Nico, 2015-03-04 19:03:35]

lgtm, but in general I think having the target unconditionally and making it
type-none conditionally is preferable. That way, clients can have an
unconditional dependency, instead of every client duplicating the exact
condition for when the target exists when adding a dep.

[scottmg, 2015-03-04 19:12:06]

On 2015/03/04 19:03:35, Nico wrote:
> lgtm, but in general I think having the target unconditionally and making it
> type-none conditionally is preferable. That way, clients can have an
> unconditional dependency, instead of every client duplicating the exact
> condition for when the target exists when adding a dep.

Makes sense. I added an else branch (I don't think the condition can go directy
on 'type'?.. it'd be a bit odd to have dependencies and sources for the none
target anyway.)

[Nico, 2015-03-04 19:22:12]

On 2015/03/04 19:12:06, scottmg wrote:
> On 2015/03/04 19:03:35, Nico wrote:
> > lgtm, but in general I think having the target unconditionally and making it
> > type-none conditionally is preferable. That way, clients can have an
> > unconditional dependency, instead of every client duplicating the exact
> > condition for when the target exists when adding a dep.
> 
> Makes sense. I added an else branch (I don't think the condition can go
directy
> on 'type'?

Pretty sure it can…yeah, see these examples:
https://code.google.com/p/chromium/codesearch#search/&q=pcre:yes%20target_nam...

>.. it'd be a bit odd to have dependencies and sources for the none
> target anyway.)

[scottmg, 2015-03-04 19:39:52]

On 2015/03/04 19:22:12, Nico wrote:
> On 2015/03/04 19:12:06, scottmg wrote:
> > On 2015/03/04 19:03:35, Nico wrote:
> > > lgtm, but in general I think having the target unconditionally and making
it
> > > type-none conditionally is preferable. That way, clients can have an
> > > unconditional dependency, instead of every client duplicating the exact
> > > condition for when the target exists when adding a dep.
> > 
> > Makes sense. I added an else branch (I don't think the condition can go
> directy
> > on 'type'?
> 
> Pretty sure it can…yeah, see these examples:
>
https://code.google.com/p/chromium/codesearch#search/&q=pcre:yes%20target_nam...

TIL: `pcre:yes`!

4th time's the charm.

> >.. it'd be a bit odd to have dependencies and sources for the none
> > target anyway.)

[Nico, 2015-03-04 19:43:08]

lgtm!

Yes, I was amazed when I discovered pcre:yes a while ago, but somehow missed to
tell others about it. Well, fixed now ;-)

[scottmg, 2015-03-04 20:20:44]

The CQ bit was checked by scottmg@chromium.org

[commit-bot: I haz the power, 2015-03-04 20:26:39]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/981623002/60001

[commit-bot: I haz the power, 2015-03-04 20:38:31]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-03-04 20:39:39]

Patchset 4 (id:??) landed as
https://crrev.com/a03124d1119077caad658d8a39e59365ca64541d
Cr-Commit-Position: refs/heads/master@{#319119}

[pasko, 2015-03-05 15:42:56]

lgtm fwiw