GPU: Split some of the GPU projects to individual gypi files.

GPU: Split some of the GPU projects to individual gypi files.

There should be no change in behavior.

BUG=114261
TEST=none
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=122413

[rvargas (doing something else), 2012-02-15 03:23:05]

Please take a look.

Patch set 2 is easier to digest. PS 3 just fixes the indentation (but ruins the
diff).

[Dirk Pranke, 2012-02-16 02:24:41]

looks plausible to me but Gregg's probably the better person to bless it.

[greggman, 2012-02-16 02:54:28]

On 2012/02/16 02:24:41, Dirk Pranke wrote:
> looks plausible to me but Gregg's probably the better person to bless it.

before I approve this can I have some context? This doesn't seem to be a
functional change. Is there some new style guide and mandates this? Does it
allow parallel building or something?

[Dirk Pranke, 2012-02-16 04:02:18]

On 2012/02/16 02:54:28, greggman wrote:
> On 2012/02/16 02:24:41, Dirk Pranke wrote:
> > looks plausible to me but Gregg's probably the better person to bless it.
> 
> before I approve this can I have some context? This doesn't seem to be a
> functional change. Is there some new style guide and mandates this? Does it
> allow parallel building or something?

I think it's just a bunch of refactoring changes that allows us to delete
hundreds of lines of copied/pasted code.

[rvargas (doing something else), 2012-02-16 04:06:44]

On 2012/02/16 02:54:28, greggman wrote:
> On 2012/02/16 02:24:41, Dirk Pranke wrote:
> > looks plausible to me but Gregg's probably the better person to bless it.
> 
> before I approve this can I have some context? This doesn't seem to be a
> functional change. Is there some new style guide and mandates this? Does it
> allow parallel building or something?

The linked bug is about moving GPU to be built as a DLL. We need that because
chrome/common depends on GPU, and that means that unless nobody else depends on
GPU code (and that's obviously not the case), GPU cannot be static libraries. Of
course, the real objective is splitting the code under chrome.

The question is how many. I don't like the idea of having 10 different GPU DLLs
(one for each project), especially since some projects are just a couple of
files. So far, it looks like we can live with 2 new DLLs: one for the code that
you reviewed, and another one for the rest of the solution (in other words the 6
projects that I'm splitting here).

I want to make the change easy to review, so I'm staring with just splitting the
files. In the future, we'll switch between a single project for the shared
build, and independent projects for the static build. That follows the pattern
used in content (hence having Dirk seeing this review).

[greggman, 2012-02-16 05:05:03]

On 2012/02/16 04:06:44, rvargas wrote:
> On 2012/02/16 02:54:28, greggman wrote:
> > On 2012/02/16 02:24:41, Dirk Pranke wrote:
> > > looks plausible to me but Gregg's probably the better person to bless it.
> > 
> > before I approve this can I have some context? This doesn't seem to be a
> > functional change. Is there some new style guide and mandates this? Does it
> > allow parallel building or something?
> 
> The linked bug is about moving GPU to be built as a DLL. We need that because
> chrome/common depends on GPU, and that means that unless nobody else depends
on
> GPU code (and that's obviously not the case), GPU cannot be static libraries.
Of
> course, the real objective is splitting the code under chrome.
> 
> The question is how many. I don't like the idea of having 10 different GPU
DLLs
> (one for each project), especially since some projects are just a couple of
> files. So far, it looks like we can live with 2 new DLLs: one for the code
that
> you reviewed, and another one for the rest of the solution (in other words the
6
> projects that I'm splitting here).
> 
> I want to make the change easy to review, so I'm staring with just splitting
the
> files. In the future, we'll switch between a single project for the shared
> build, and independent projects for the static build. That follows the pattern
> used in content (hence having Dirk seeing this review).

So this is different from Dirk making it a component yea? Okay, whatever. I
don't want to stand in the way of progress. I'm just not sure where there is
leading. Anything in client and common has to be compiled twice. Once using the
platform's gcc and again using NaCl so while you can turn one version into a dll
I'm not sure what that means for all this stuff.

Are you putting the batches of lists into separate files because you're going to
include them from other places? 

Whatever your big change is, please build "compressed_textures_exe" and make
sure it runs. Also follow the instructions in gpu/gles2_conform_test/README and
make and run that.

Unfortunately neither of those are in any bots .... yet .... as such, changes
here often break them.


LGTM

[Dirk Pranke, 2012-02-16 06:03:23]

On Wed, Feb 15, 2012 at 9:05 PM,  <gman@chromium.org> wrote:
> On 2012/02/16 04:06:44, rvargas wrote:
>>
>> On 2012/02/16 02:54:28, greggman wrote:
>> > On 2012/02/16 02:24:41, Dirk Pranke wrote:
>> > > looks plausible to me but Gregg's probably the better person to bless
>> > > it.
>> >
>> > before I approve this can I have some context? This doesn't seem to be a
>> > functional change. Is there some new style guide and mandates this? Does
>> > it
>> > allow parallel building or something?
>
>
>> The linked bug is about moving GPU to be built as a DLL. We need that
>> because
>> chrome/common depends on GPU, and that means that unless nobody else
>> depends
>
> on
>>
>> GPU code (and that's obviously not the case), GPU cannot be static
>> libraries.
>
> Of
>>
>> course, the real objective is splitting the code under chrome.
>
>
>> The question is how many. I don't like the idea of having 10 different GPU
>
> DLLs
>>
>> (one for each project), especially since some projects are just a couple
>> of
>> files. So far, it looks like we can live with 2 new DLLs: one for the code
>
> that
>>
>> you reviewed, and another one for the rest of the solution (in other words
>> the
>
> 6
>>
>> projects that I'm splitting here).
>
>
>> I want to make the change easy to review, so I'm staring with just
>> splitting
>
> the
>>
>> files. In the future, we'll switch between a single project for the shared
>> build, and independent projects for the static build. That follows the
>> pattern
>> used in content (hence having Dirk seeing this review).
>
>
> So this is different from Dirk making it a component yea? Okay, whatever.

I only made gles2_c_lib a component. Sounds like Ricardo's making
everything else componentizable (if that's even a word).

-- Dirk