Move webkit/fileapi/file_system_mount_point_provider.h to webkit/browser/fileapi

Move webkit/fileapi/file_system_mount_point_provider.h to webkit/browser/fileapi

This one also:
- Adds webkit/browser dependency to chrome/browser/DEPS (with TODO)
- Adds webkit/browser/webkit_browser.gypi which only defines new source list
  for now (will make build target changes later)

More bulk file moving is coming later

BUG=239710
R=jamesr@chromium.org, michaeln@chromium.org, thestig@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=200828

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=201034

[kinuko, 2013-05-14 15:19:17]

The first cut for bulk moving in webkit/. It's a bit rough but let me share this
with you anyway. (I can split this if it's too big)

No components / build target changes in this CL yet, I just moved files and
added tentative gypi files. (Therefore they're just built as a part of
webkit_storage component)

Michael &| james: can you take a look? Thanks!

[michaeln, 2013-05-15 00:19:38]

so move files first, then fix gyps to construct new build targets... works for
me

https://codereview.chromium.org/14895013/diff/74001/webkit/browser/webkit_bro...
File webkit/browser/webkit_browser_storage.gypi (right):

https://codereview.chromium.org/14895013/diff/74001/webkit/browser/webkit_bro...
webkit/browser/webkit_browser_storage.gypi:9: # TODO(kinuko): Have
webkit_browser_storage target and deprecate
Q: Do we want a webkit_browser_storage target or just one larger webkit_browser
target which includes the storage bits? I have no preference really and either
will work, just want to nail down what it is that we're collectively shooting
for.

Independent of that, having this intermediary gypi that gathers up the 'storage'
sources sgtm so it'll be a one-liner to pull all sources into whatever .gyp
target we do decide on.

Would like to hear james's pov.

[kinuko, 2013-05-15 04:45:26]

On 2013/05/15 00:19:38, michaeln wrote:
> so move files first, then fix gyps to construct new build targets... works for
> me
> 
>
https://codereview.chromium.org/14895013/diff/74001/webkit/browser/webkit_bro...
> File webkit/browser/webkit_browser_storage.gypi (right):
> 
>
https://codereview.chromium.org/14895013/diff/74001/webkit/browser/webkit_bro...
> webkit/browser/webkit_browser_storage.gypi:9: # TODO(kinuko): Have
> webkit_browser_storage target and deprecate
> Q: Do we want a webkit_browser_storage target or just one larger
webkit_browser
> target which includes the storage bits? I have no preference really and either
> will work, just want to nail down what it is that we're collectively shooting
> for.

Right, that's the point I wanted to hear your opinion. Maybe we can go with this
intermediary gypi while/before we decide what targets we'll have? (I'll update
the TODO comment and issue about this as well)

> Independent of that, having this intermediary gypi that gathers up the
'storage'
> sources sgtm so it'll be a one-liner to pull all sources into whatever .gyp
> target we do decide on.
> 
> Would like to hear james's pov.

[kinuko, 2013-05-15 08:00:25]

Narrowed down the scope to move only one file to start with.

michaeln/jamesr: can you PTAL at webkit/**.gypi changes?

(Again, no component / build target changes yet)

[michaeln, 2013-05-15 18:44:38]

lgtm

Fortunately, we don't need to decide just yet on the build target(s) question to
start moving things around and describing the moves files.gypi. I'm pretty keen
to move other things into the new directory and webkit_storage.gypi, i think
building as usual for the time being makes the file moving part easier.

Once we have things moved around, we can revisit the 'how to build them into
what targets' question. When we get there... smaller targets for
webkit_*_storage might be easier to manage because we can pull that off
independent of what's happening with say "glue" or other stuff in /webkit.

(rietveld showing the files is snapshot2 as 'deleted' had me confused:)

[jamesr, 2013-05-15 19:14:08]

lgtm2.

Personally, I don't really understand why there are so many .gypis in webkit/ -
I find declaring targets/etc inside gypis really confusing compared to just
declaring targets in a .gyp file per directory and reserving .gypis for
variables/whatnot that are shared between multiple .gyp files.

[kinuko, 2013-05-16 05:29:06]

On 2013/05/15 19:14:08, jamesr wrote:
> lgtm2.
> 
> Personally, I don't really understand why there are so many .gypis in webkit/
-
> I find declaring targets/etc inside gypis really confusing compared to just
> declaring targets in a .gyp file per directory and reserving .gypis for
> variables/whatnot that are shared between multiple .gyp files.

I might be adding too many. I swear I'll cleanup them in the series of patches!

[kinuko, 2013-05-16 06:08:18]

jochen: can you review chrome/ changes? (Namely chrome/browser/DEPS. Other
changes must be innocent)

[kinuko, 2013-05-16 10:17:12]

(Looks like jochen's not there)

Darin: can you stamp for chrome/browser/DEPS change?

(Adding chrome/browser => webkit/browser dependency along the line
http://crbug.com/239107#c3)

[kinuko, 2013-05-17 05:52:38]

Picking another chrome/ OWNER, in an assumption that chrome/browser/DEPS change
is casually approved by Darin in http://crbug.com/239107#c6

thestig: mind taking a look at chrome/ changes? (most are mechanical other than
DEPS one)
darin: please shout out if you have comments.

Thanks!

[Lei Zhang, 2013-05-17 07:53:44]

lgtm

[commit-bot: I haz the power, 2013-05-17 16:08:40]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/kinuko@chromium.org/14895013/149001

[kinuko, 2013-05-17 16:44:34]

Committed patchset #4 manually as r200828.

[kinuko, 2013-05-20 02:45:27]

Got reverted, will be relanding with one-line change in webkit_fileapi.gypi:
https://codereview.chromium.org/14895013/diff2/149001:162005/webkit/fileapi/w...

[kinuko, 2013-05-20 05:43:08]

Committed patchset #6 manually as r201034.