Make target running GLES2 autogen script.

Make target running GLES2 autogen script.

Also lays groundwork for rebuilding Pepper OpenGL ES bindings as part of the build.

BUG=none
TEST=run "make ppapi_gles_bindings" or "make ppapi_gles_implementation".

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

[greggman, 2010-11-23 00:07:19]

yea, I saw this issue and saw that it was marked closed.

I think Al and My preference are to leave this run by hand. The advantage is we
can more easily diff the differences that are generated. Any changes to the
generator, even adding a function, have the ability to break everything (the
command buffer, the Pepper 3D glue, etc). 

I could be convinced otherwise as I was about to do this myself last week for
the command buffer part and Al chimed in with "it's good to be able to diff the
changes"

Al?

[apatrick, 2010-11-23 02:09:47]

How about we keep the generated source in the repository and the python
script just verifies that it is up-to-date as a build action. Maybe
auto-generate it into an intermediate directory and then diff it against the
one in subversion.

On Mon, Nov 22, 2010 at 4:07 PM, <gman@chromium.org> wrote:

> yea, I saw this issue and saw that it was marked closed.
>
> I think Al and My preference are to leave this run by hand. The advantage
> is we
> can more easily diff the differences that are generated. Any changes to the
> generator, even adding a function, have the ability to break everything
> (the
> command buffer, the Pepper 3D glue, etc).
>
> I could be convinced otherwise as I was about to do this myself last week
> for
> the command buffer part and Al chimed in with "it's good to be able to diff
> the
> changes"
>
> Al?
>
>
> http://codereview.chromium.org/5212006/
>

[neb, 2010-11-23 19:17:10]

Hmm. I could just not delete the autogen'ed file. That way svn diff will tell
you the difference in a pretty obvious way, and the red is there to remind you
to check it in, so that we can have the history in svn too.

I don't want to leave the pepper stuff to manual generation. It fell out of
whack more than once, and I don't want to maintain it. This way if it gets
broken it'll break the build.


On 2010/11/23 02:09:47, apatrick wrote:
> How about we keep the generated source in the repository and the python
> script just verifies that it is up-to-date as a build action. Maybe
> auto-generate it into an intermediate directory and then diff it against the
> one in subversion.
> 
> On Mon, Nov 22, 2010 at 4:07 PM, <mailto:gman@chromium.org> wrote:
> 
> > yea, I saw this issue and saw that it was marked closed.
> >
> > I think Al and My preference are to leave this run by hand. The advantage
> > is we
> > can more easily diff the differences that are generated. Any changes to the
> > generator, even adding a function, have the ability to break everything
> > (the
> > command buffer, the Pepper 3D glue, etc).
> >
> > I could be convinced otherwise as I was about to do this myself last week
> > for
> > the command buffer part and Al chimed in with "it's good to be able to diff
> > the
> > changes"
> >
> > Al?
> >
> >
> > http://codereview.chromium.org/5212006/
> >

[neb, 2011-01-29 03:43:34]

Hey guys,

I'm getting around to working on 3d again, and I want to run this script every
now and then. How about landing this change which doesn't run the script as part
of the build, but makes a gyp target that I can run manually?

[neb, 2011-01-29 03:45:20]

Updated description.

[greggman, 2011-01-30 00:37:00]

lgtm

[apatrick, 2011-01-31 18:24:04]

LGTM

[gavinp, 2011-02-08 18:58:30]

Aren't , webkit/plugins/ppapi/ppb_opengles_impl.cc, ppapi/lib/gl/gles2/gles2.c
and ppapi/c/dev/ppb_opengles_dev.h still checked into our repository?

This change means that the mere act of doing a build causes you to instantly get
merge conflicts if you do later updates, or want to switch repos.  This is
pretty bad practice!  Shouldn't this be reverted or fixed pronto?