Start moving core pieces of Chrome multi-process code to src\content.

Start moving core pieces of Chrome multi-process code to src\content.  I'm starting with tab_contents directory.In future changes the headers that include these files will be updated.  Once all the files are moved (i.e. renderer_host, rest of browser, renderer etc), then refactoring can begin so that content\DEPS doesn't have chrome in it.

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

[bradn, 2011-02-17 18:01:31]

So this looks ok.
But it actually makes me want to revisit something with mark.
A substantial part of why chrome.gyp is chopped up into a bunch of gypi's rather
than having .gyp's at each level is that this results in lots of layers in
xcode.
I just want to reconfirm with Mark that the scale of the project doesn't now
warrant finer granularity in the .gyp's ?
I hope to very soon eliminate all the win64 duplication that's floating around,
and in the same spirit, it does seem that the gyp files would be easier to
understand if they used cross directory dependencies rather than includes.
What do you think Mark?

[Mark Mentovai, 2011-02-17 18:15:03]

I don’t know what you mean by “layers in Xcode.” Certainly, though,
the circular-dependency thing could easily become a factor in chrome/:
we can’t have any circular relationships between .gyp files, even
independent of relationships between targets.

[bradn, 2011-02-17 18:37:06]

On Thu, Feb 17, 2011 at 10:14 AM, Mark Mentovai <mark@chromium.org> wrote:

> I don’t know what you mean by “layers in Xcode.” Certainly, though,
>
Sorry didn't express that well.
I meant that you'd been in favor of keeping chrome.gyp...large on the ground
that then it comes up in a single xcodeproj, which was more aesthetic /
functional than lots of little projects that you'd have to drill down into
to get to the sources.
Is this still a concern?


> the circular-dependency thing could easily become a factor in chrome/:
> we can’t have any circular relationships between .gyp files, even
> independent of relationships between targets.
>

I'd completely forgotten about this problem.
That would certainly prove to be an issue with moving chrome_*.gypi to be
.gyp files.
For the content stuff that you're spitting off John, how modular is it? Does
it know about stuff in src/chrome and vis-versa?

-BradN

[Mark Mentovai, 2011-02-17 18:40:36]

Bradley Nelson wrote:
> Sorry didn't express that well.
> I meant that you'd been in favor of keeping chrome.gyp...large on the ground
> that then it comes up in a single xcodeproj, which was more aesthetic /
> functional than lots of little projects that you'd have to drill down into
> to get to the sources.
> Is this still a concern?

Well, it depends on how things get broken up. Generally, though, I do
think that most Mac developers expect to find all of the “chrome”
files available for editing in that one .xcodeproj.

[jam, 2011-02-17 18:46:10]

On Thu, Feb 17, 2011 at 10:36 AM, Bradley Nelson <bradnelson@google.com>wrote:

>
>
> On Thu, Feb 17, 2011 at 10:14 AM, Mark Mentovai <mark@chromium.org> wrote:
>
>> I don’t know what you mean by “layers in Xcode.” Certainly, though,
>>
> Sorry didn't express that well.
> I meant that you'd been in favor of keeping chrome.gyp...large on the
> ground that then it comes up in a single xcodeproj, which was
> more aesthetic / functional than lots of little projects that you'd have to
> drill down into to get to the sources.
> Is this still a concern?
>
>
>> the circular-dependency thing could easily become a factor in chrome/:
>> we can’t have any circular relationships between .gyp files, even
>> independent of relationships between targets.
>>
>
> I'd completely forgotten about this problem.
> That would certainly prove to be an issue with moving chrome_*.gypi to be
> .gyp files.
> For the content stuff that you're spitting off John, how modular is it?
> Does it know about stuff in src/chrome and vis-versa?
>

content won't have any gyp dependency on chrome.  Currently, until the
refactoring is complete, files there will #include headers from chrome.  but
gyp won't.  that's fine right?


>
> -BradN
>
>

[jam, 2011-02-17 18:46:57]

Thanks for taking a look btw!

On Thu, Feb 17, 2011 at 10:46 AM, John Abd-El-Malek <jam@chromium.org>wrote:

>
>
> On Thu, Feb 17, 2011 at 10:36 AM, Bradley Nelson <bradnelson@google.com>wrote:
>
>>
>>
>> On Thu, Feb 17, 2011 at 10:14 AM, Mark Mentovai <mark@chromium.org>wrote:
>>
>>> I don’t know what you mean by “layers in Xcode.” Certainly, though,
>>>
>> Sorry didn't express that well.
>> I meant that you'd been in favor of keeping chrome.gyp...large on the
>> ground that then it comes up in a single xcodeproj, which was
>> more aesthetic / functional than lots of little projects that you'd have to
>> drill down into to get to the sources.
>> Is this still a concern?
>>
>>
>>> the circular-dependency thing could easily become a factor in chrome/:
>>> we can’t have any circular relationships between .gyp files, even
>>> independent of relationships between targets.
>>>
>>
>> I'd completely forgotten about this problem.
>> That would certainly prove to be an issue with moving chrome_*.gypi to be
>> .gyp files.
>> For the content stuff that you're spitting off John, how modular is it?
>> Does it know about stuff in src/chrome and vis-versa?
>>
>
> content won't have any gyp dependency on chrome.  Currently, until the
> refactoring is complete, files there will #include headers from chrome.  but
> gyp won't.  that's fine right?
>
>
>>
>> -BradN
>>
>>
>

[bradn, 2011-02-17 18:47:47]

On Thu, Feb 17, 2011 at 10:46 AM, John Abd-El-Malek <jam@chromium.org>wrote:

>
>
> On Thu, Feb 17, 2011 at 10:36 AM, Bradley Nelson <bradnelson@google.com>wrote:
>
>>
>>
>> On Thu, Feb 17, 2011 at 10:14 AM, Mark Mentovai <mark@chromium.org>wrote:
>>
>>> I don’t know what you mean by “layers in Xcode.” Certainly, though,
>>>
>> Sorry didn't express that well.
>> I meant that you'd been in favor of keeping chrome.gyp...large on the
>> ground that then it comes up in a single xcodeproj, which was
>> more aesthetic / functional than lots of little projects that you'd have to
>> drill down into to get to the sources.
>> Is this still a concern?
>>
>>
>>> the circular-dependency thing could easily become a factor in chrome/:
>>> we can’t have any circular relationships between .gyp files, even
>>> independent of relationships between targets.
>>>
>>
>> I'd completely forgotten about this problem.
>> That would certainly prove to be an issue with moving chrome_*.gypi to be
>> .gyp files.
>> For the content stuff that you're spitting off John, how modular is it?
>> Does it know about stuff in src/chrome and vis-versa?
>>
>
> content won't have any gyp dependency on chrome.  Currently, until the
> refactoring is complete, files there will #include headers from chrome.  but
> gyp won't.  that's fine right?
>
Probably ok, unless you're talking about any generated headers.




>
>
>>
>> -BradN
>>
>>
>

[bradn, 2011-02-17 18:49:49]

So given Mark's response. I'd say you might want to consider switching the
.gypi's you've got to .gyp's down in each directory.
Unless they'll end up being really small?
I guess my take is that breaking apart large .gyp's is good, but you should
avoid gypi's whenever you can in favor of separate .gyp's, preferably ones
in different directories.

-BradN

On Thu, Feb 17, 2011 at 10:47 AM, Bradley Nelson <bradnelson@google.com>wrote:

>
>
> On Thu, Feb 17, 2011 at 10:46 AM, John Abd-El-Malek <jam@chromium.org>wrote:
>
>>
>>
>> On Thu, Feb 17, 2011 at 10:36 AM, Bradley Nelson
<bradnelson@google.com>wrote:
>>
>>>
>>>
>>> On Thu, Feb 17, 2011 at 10:14 AM, Mark Mentovai <mark@chromium.org>wrote:
>>>
>>>> I don’t know what you mean by “layers in Xcode.” Certainly, though,
>>>>
>>> Sorry didn't express that well.
>>> I meant that you'd been in favor of keeping chrome.gyp...large on the
>>> ground that then it comes up in a single xcodeproj, which was
>>> more aesthetic / functional than lots of little projects that you'd have to
>>> drill down into to get to the sources.
>>> Is this still a concern?
>>>
>>>
>>>> the circular-dependency thing could easily become a factor in chrome/:
>>>> we can’t have any circular relationships between .gyp files, even
>>>> independent of relationships between targets.
>>>>
>>>
>>> I'd completely forgotten about this problem.
>>> That would certainly prove to be an issue with moving chrome_*.gypi to be
>>> .gyp files.
>>> For the content stuff that you're spitting off John, how modular is it?
>>> Does it know about stuff in src/chrome and vis-versa?
>>>
>>
>> content won't have any gyp dependency on chrome.  Currently, until the
>> refactoring is complete, files there will #include headers from chrome.  but
>> gyp won't.  that's fine right?
>>
> Probably ok, unless you're talking about any generated headers.
>
>
>
>
>>
>>
>>>
>>> -BradN
>>>
>>>
>>
>

[jam, 2011-02-17 18:57:19]

On Thu, Feb 17, 2011 at 10:49 AM, Bradley Nelson <bradnelson@google.com>wrote:

> So given Mark's response. I'd say you might want to consider switching the
> .gypi's you've got to .gyp's down in each directory.
> Unless they'll end up being really small?
> I guess my take is that breaking apart large .gyp's is good, but you should
> avoid gypi's whenever you can in favor of separate .gyp's, preferably ones
> in different directories.
>

I'm a little lost here.  To answer the easy question, I don't think they'll
be that small.

so you're saying have content\content.gyp that has a dependency on
content\browser\content_browser.gyp?

part of my confusion is I don't understand why one would use gyp vs gypi,
and the tradeoffs involved.  Mark said people expect to find all the files
in one .xcodeproj file.  Doesn't each gyp generate one such file?


>
> -BradN
>
>
> On Thu, Feb 17, 2011 at 10:47 AM, Bradley Nelson <bradnelson@google.com>wrote:
>
>>
>>
>> On Thu, Feb 17, 2011 at 10:46 AM, John Abd-El-Malek <jam@chromium.org>wrote:
>>
>>>
>>>
>>> On Thu, Feb 17, 2011 at 10:36 AM, Bradley Nelson
<bradnelson@google.com>wrote:
>>>
>>>>
>>>>
>>>> On Thu, Feb 17, 2011 at 10:14 AM, Mark Mentovai <mark@chromium.org>wrote:
>>>>
>>>>> I don’t know what you mean by “layers in Xcode.” Certainly, though,
>>>>>
>>>> Sorry didn't express that well.
>>>> I meant that you'd been in favor of keeping chrome.gyp...large on the
>>>> ground that then it comes up in a single xcodeproj, which was
>>>> more aesthetic / functional than lots of little projects that you'd have to
>>>> drill down into to get to the sources.
>>>> Is this still a concern?
>>>>
>>>>
>>>>> the circular-dependency thing could easily become a factor in chrome/:
>>>>> we can’t have any circular relationships between .gyp files, even
>>>>> independent of relationships between targets.
>>>>>
>>>>
>>>> I'd completely forgotten about this problem.
>>>> That would certainly prove to be an issue with moving chrome_*.gypi to
>>>> be .gyp files.
>>>> For the content stuff that you're spitting off John, how modular is it?
>>>> Does it know about stuff in src/chrome and vis-versa?
>>>>
>>>
>>> content won't have any gyp dependency on chrome.  Currently, until the
>>> refactoring is complete, files there will #include headers from chrome.  but
>>> gyp won't.  that's fine right?
>>>
>> Probably ok, unless you're talking about any generated headers.
>>
>>
>>
>>
>>>
>>>
>>>>
>>>> -BradN
>>>>
>>>>
>>>
>>
>

[bradn, 2011-02-17 19:08:26]

Oh sorry, I miss read Mark's reply.

In light of that, your CL seems ok as is.
As it avoids chopping things into super large pieces.
Mark are you ok with this stuff appearing in a separate xcodeproj ?

-BradN


On Thu, Feb 17, 2011 at 10:57 AM, John Abd-El-Malek <jam@chromium.org>wrote:

>
>
> On Thu, Feb 17, 2011 at 10:49 AM, Bradley Nelson <bradnelson@google.com>wrote:
>
>> So given Mark's response. I'd say you might want to consider switching the
>> .gypi's you've got to .gyp's down in each directory.
>> Unless they'll end up being really small?
>> I guess my take is that breaking apart large .gyp's is good, but you
>> should avoid gypi's whenever you can in favor of separate
>> .gyp's, preferably ones in different directories.
>>
>
> I'm a little lost here.  To answer the easy question, I don't think they'll
> be that small.
>
> so you're saying have content\content.gyp that has a dependency on
> content\browser\content_browser.gyp?
>
> part of my confusion is I don't understand why one would use gyp vs gypi,
> and the tradeoffs involved.  Mark said people expect to find all the files
> in one .xcodeproj file.  Doesn't each gyp generate one such file?
>
>
>>
>> -BradN
>>
>>
>> On Thu, Feb 17, 2011 at 10:47 AM, Bradley Nelson
<bradnelson@google.com>wrote:
>>
>>>
>>>
>>> On Thu, Feb 17, 2011 at 10:46 AM, John Abd-El-Malek <jam@chromium.org>wrote:
>>>
>>>>
>>>>
>>>> On Thu, Feb 17, 2011 at 10:36 AM, Bradley Nelson <bradnelson@google.com
>>>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 17, 2011 at 10:14 AM, Mark Mentovai <mark@chromium.org>wrote:
>>>>>
>>>>>> I don’t know what you mean by “layers in Xcode.” Certainly, though,
>>>>>>
>>>>> Sorry didn't express that well.
>>>>> I meant that you'd been in favor of keeping chrome.gyp...large on the
>>>>> ground that then it comes up in a single xcodeproj, which was
>>>>> more aesthetic / functional than lots of little projects that you'd have
to
>>>>> drill down into to get to the sources.
>>>>> Is this still a concern?
>>>>>
>>>>>
>>>>>> the circular-dependency thing could easily become a factor in chrome/:
>>>>>> we can’t have any circular relationships between .gyp files, even
>>>>>> independent of relationships between targets.
>>>>>>
>>>>>
>>>>> I'd completely forgotten about this problem.
>>>>> That would certainly prove to be an issue with moving chrome_*.gypi to
>>>>> be .gyp files.
>>>>> For the content stuff that you're spitting off John, how modular is it?
>>>>> Does it know about stuff in src/chrome and vis-versa?
>>>>>
>>>>
>>>> content won't have any gyp dependency on chrome.  Currently, until the
>>>> refactoring is complete, files there will #include headers from chrome. 
but
>>>> gyp won't.  that's fine right?
>>>>
>>> Probably ok, unless you're talking about any generated headers.
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> -BradN
>>>>>
>>>>>
>>>>
>>>
>>
>

[Mark Mentovai, 2011-02-17 19:23:00]

I don’t have a strong preference, personally.

[jam, 2011-02-17 19:46:44]

On Thu, Feb 17, 2011 at 11:08 AM, Bradley Nelson <bradnelson@google.com>wrote:

> Oh sorry, I miss read Mark's reply.
>
> In light of that, your CL seems ok as is.
> As it avoids chopping things into super large pieces.
> Mark are you ok with this stuff appearing in a separate xcodeproj ?
>

Just so I'm clear, do you mean whether it's ok to have
src\content\content.gyp vs content.gypi?  You're not talking about the
subdirectories right?

I personally don't care about gyp vs gypi.  Note that one long term plan,
once this is all done (it'll take a while :) ), is to have a multi-process
test shell.  Not sure if that influences gyp vs gypi for content.

>
> -BradN
>
>
> On Thu, Feb 17, 2011 at 10:57 AM, John Abd-El-Malek <jam@chromium.org>wrote:
>
>>
>>
>> On Thu, Feb 17, 2011 at 10:49 AM, Bradley Nelson
<bradnelson@google.com>wrote:
>>
>>> So given Mark's response. I'd say you might want to consider switching
>>> the .gypi's you've got to .gyp's down in each directory.
>>> Unless they'll end up being really small?
>>> I guess my take is that breaking apart large .gyp's is good, but you
>>> should avoid gypi's whenever you can in favor of separate
>>> .gyp's, preferably ones in different directories.
>>>
>>
>> I'm a little lost here.  To answer the easy question, I don't think
>> they'll be that small.
>>
>> so you're saying have content\content.gyp that has a dependency on
>> content\browser\content_browser.gyp?
>>
>> part of my confusion is I don't understand why one would use gyp vs gypi,
>> and the tradeoffs involved.  Mark said people expect to find all the files
>> in one .xcodeproj file.  Doesn't each gyp generate one such file?
>>
>>
>>>
>>> -BradN
>>>
>>>
>>> On Thu, Feb 17, 2011 at 10:47 AM, Bradley Nelson
<bradnelson@google.com>wrote:
>>>
>>>>
>>>>
>>>> On Thu, Feb 17, 2011 at 10:46 AM, John Abd-El-Malek
<jam@chromium.org>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 17, 2011 at 10:36 AM, Bradley Nelson <
>>>>> bradnelson@google.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 17, 2011 at 10:14 AM, Mark Mentovai <mark@chromium.org>wrote:
>>>>>>
>>>>>>> I don’t know what you mean by “layers in Xcode.” Certainly, though,
>>>>>>>
>>>>>> Sorry didn't express that well.
>>>>>> I meant that you'd been in favor of keeping chrome.gyp...large on the
>>>>>> ground that then it comes up in a single xcodeproj, which was
>>>>>> more aesthetic / functional than lots of little projects that you'd have
to
>>>>>> drill down into to get to the sources.
>>>>>> Is this still a concern?
>>>>>>
>>>>>>
>>>>>>> the circular-dependency thing could easily become a factor in
>>>>>>> chrome/:
>>>>>>> we can’t have any circular relationships between .gyp files, even
>>>>>>> independent of relationships between targets.
>>>>>>>
>>>>>>
>>>>>> I'd completely forgotten about this problem.
>>>>>> That would certainly prove to be an issue with moving chrome_*.gypi to
>>>>>> be .gyp files.
>>>>>> For the content stuff that you're spitting off John, how modular is
>>>>>> it? Does it know about stuff in src/chrome and vis-versa?
>>>>>>
>>>>>
>>>>> content won't have any gyp dependency on chrome.  Currently, until the
>>>>> refactoring is complete, files there will #include headers from chrome. 
but
>>>>> gyp won't.  that's fine right?
>>>>>
>>>> Probably ok, unless you're talking about any generated headers.
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> -BradN
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

[jam, 2011-02-17 23:06:49]

Brett/Avi for review.  Darin/Ben: in case you have any comments if I moved more
than I should.  Brad has answered my questions re the gyp stuff, so I think that
part is settled.

[Avi (use Gerrit), 2011-02-17 23:28:39]

Code LG. gyp, can't say, though I have a comment.

http://codereview.chromium.org/6537015/diff/7001/chrome/chrome_tests.gypi
File chrome/chrome_tests.gypi (right):

http://codereview.chromium.org/6537015/diff/7001/chrome/chrome_tests.gypi#new...
chrome/chrome_tests.gypi:1805:
'browser/tab_contents/render_view_host_manager_unittest.cc',
Did you mean 'content/browser...'?

[jam, 2011-02-18 03:14:41]

can you take another look?  to avoid the circular dependency on Mac's gyp
checking, I've had to take all the strings out of this.  Something that needs to
be done anyways, since they're all related to UI by definition.

[Avi (use Gerrit), 2011-02-18 03:51:48]

SLGTM. I'll probably do some refactoring on TCW later; I want it to be just a
collection of TabHelpers.

[Ben Goodger (Google), 2011-02-18 04:04:49]

So you decided to go with the "browser" name for the code that runs in the
embedding process?

-Ben

On Thu, Feb 17, 2011 at 3:06 PM, <jam@chromium.org> wrote:

> Brett/Avi for review.  Darin/Ben: in case you have any comments if I moved
> more
> than I should.  Brad has answered my questions re the gyp stuff, so I think
> that
> part is settled.
>
>
>
>
> http://codereview.chromium.org/6537015/
>

[Ben Goodger (Google), 2011-02-18 04:08:30]

I'm OK with this step knowing that you're using stub headers and we can
shuffle/rename a few of these before having to update the rest of the codebase.

http://codereview.chromium.org/6537015/diff/7015/content/OWNERS
File content/OWNERS (right):

http://codereview.chromium.org/6537015/diff/7015/content/OWNERS#newcode4
content/OWNERS:4: brett@chromium.org
brettw@

http://codereview.chromium.org/6537015/diff/7015/content/content_browser.gypi
File content/content_browser.gypi (right):

http://codereview.chromium.org/6537015/diff/7015/content/content_browser.gypi...
content/content_browser.gypi:8: 'target_name': 'content_browser',
Can these gypi files live in the subdirs? That makes them closer to the files
they affect. I dislike having to cd up to src/chrome whenever I add a file in
src/chrome/browser/ui/views for example.

[jam, 2011-02-18 05:17:35]

sounds good

On Thu, Feb 17, 2011 at 7:51 PM, <avi@chromium.org> wrote:

> SLGTM. I'll probably do some refactoring on TCW later; I want it to be just
> a
> collection of TabHelpers.
>
>
> http://codereview.chromium.org/6537015/
>

[darin (slow to review), 2011-02-18 05:18:35]

My only comment is:  This is so awesome!!1!

On Thu, Feb 17, 2011 at 3:06 PM, <jam@chromium.org> wrote:

> Brett/Avi for review.  Darin/Ben: in case you have any comments if I moved
> more
> than I should.  Brad has answered my questions re the gyp stuff, so I think
> that
> part is settled.
>
>
>
>
> http://codereview.chromium.org/6537015/
>

[jam, 2011-02-18 05:18:47]

I didn't think of anything better.  browser has the advantage that people
are already familiar with it, and it mirrors the src\chrome side.  the more
they mirror each other the easier i think for people to figure out where the
implementation and respective embedder code is.

On Thu, Feb 17, 2011 at 8:04 PM, Ben Goodger (Google) <ben@chromium.org>wrote:

> So you decided to go with the "browser" name for the code that runs in the
> embedding process?
>
> -Ben
>
>
> On Thu, Feb 17, 2011 at 3:06 PM, <jam@chromium.org> wrote:
>
>> Brett/Avi for review.  Darin/Ben: in case you have any comments if I moved
>> more
>> than I should.  Brad has answered my questions re the gyp stuff, so I
>> think that
>> part is settled.
>>
>>
>>
>>
>> http://codereview.chromium.org/6537015/
>>
>
>

[jam, 2011-02-18 05:20:17]

On Thu, Feb 17, 2011 at 8:08 PM, <ben@chromium.org> wrote:

> I'm OK with this step knowing that you're using stub headers and we can
> shuffle/rename a few of these before having to update the rest of the
> codebase.
>
>
> http://codereview.chromium.org/6537015/diff/7015/content/OWNERS
> File content/OWNERS (right):
>
> http://codereview.chromium.org/6537015/diff/7015/content/OWNERS#newcode4
> content/OWNERS:4: brett@chromium.org
> brettw@
>

fixed

>
>
> http://codereview.chromium.org/6537015/diff/7015/content/content_browser.gypi
> File content/content_browser.gypi (right):
>
>
>
http://codereview.chromium.org/6537015/diff/7015/content/content_browser.gypi...
> content/content_browser.gypi:8: 'target_name': 'content_browser',
> Can these gypi files live in the subdirs? That makes them closer to the
> files they affect. I dislike having to cd up to src/chrome whenever I
> add a file in src/chrome/browser/ui/views for example.


That's how I started it actually.  But then Brad pointed out that it's
simpler to keep it in the same dir as the gyp in src\content.  The reason is
that the file paths are relative to the gyp, not the gypi, so having them be
in different directories is confusing because when people add new files they
have to figure out which gyp includes it, and where it is.  that's why the
chrome gypis are in the chrome dir.

>
>
> http://codereview.chromium.org/6537015/
>

[Ben Goodger (Google), 2011-02-18 16:35:59]

On Thu, Feb 17, 2011 at 9:20 PM, John Abd-El-Malek <jam@chromium.org> wrote:

> That's how I started it actually.  But then Brad pointed out that it's
> simpler to keep it in the same dir as the gyp in src\content.  The reason is
> that the file paths are relative to the gyp, not the gypi, so having them be
> in different directories is confusing because when people add new files they
> have to figure out which gyp includes it, and where it is.  that's why the
> chrome gypis are in the chrome dir. \
>

That is really frustrating. I won't hold it against you in this CL though
:-)

-Ben

[jam, 2011-02-18 16:43:06]

On Fri, Feb 18, 2011 at 8:35 AM, Ben Goodger (Google) <ben@chromium.org>wrote:

> On Thu, Feb 17, 2011 at 9:20 PM, John Abd-El-Malek <jam@chromium.org>wrote:
>
>> That's how I started it actually.  But then Brad pointed out that it's
>> simpler to keep it in the same dir as the gyp in src\content.  The reason is
>> that the file paths are relative to the gyp, not the gypi, so having them be
>> in different directories is confusing because when people add new files they
>> have to figure out which gyp includes it, and where it is.  that's why the
>> chrome gypis are in the chrome dir. \
>>
>
> That is really frustrating. I won't hold it against you in this CL though
> :-)
>

Yeah I agree it's not ideal.

One thought in the back of my mind is just to get rid of the gypi files
altogether.  I believe they were added to the chrome ones to reduce
contention.  content should be fairly static, and will have a lot less files
than chrome, so maybe we can put everything in content.gyp.  Thoughts?


> -Ben
>

[Ben Goodger (Google), 2011-02-18 16:44:09]

On Friday, February 18, 2011, John Abd-El-Malek <jam@chromium.org> wrote:
> One thought in the back of my mind is just to get rid of the gypi files
altogether.  I believe they were added to the chrome ones to reduce contention.
 content should be fairly static, and will have a lot less files than chrome, so
maybe we can put everything in content.gyp.  Thoughts?

I think you're going to have more files in there than you think :-)