Introduce bindings.gyp

Introduce bindings.gyp

This CL moves the responsibility for building the bindings
from core.gyp to bindings.gyp. This CL also introduces derived_sources.gyp files, which are responsible for creating source files (but not building them).

The dependencies between these files are slightly wonky because core.gyp depends on bindings/derived_sources.gyp.  That's something we'll be able to fix once we stop core from depending on bindings directly.

BUG=230253
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=148784

[eseidel, 2013-04-10 22:58:00]

very exciting!

[Nico, 2013-04-11 05:56:36]

Very nice. I think this is all correct, lgtm.

https://codereview.chromium.org/14110002/diff/1/Source/WebCore/WebCore.gyp/We...
File Source/WebCore/WebCore.gyp/WebCore.gyp (left):

https://codereview.chromium.org/14110002/diff/1/Source/WebCore/WebCore.gyp/We...
Source/WebCore/WebCore.gyp/WebCore.gyp:2084: 'webcore_bindings',
Why is this no longer needed?

https://codereview.chromium.org/14110002/diff/1/Source/WebCore/WebCore.gypi
File Source/WebCore/WebCore.gypi (right):

https://codereview.chromium.org/14110002/diff/1/Source/WebCore/WebCore.gypi#n...
Source/WebCore/WebCore.gypi:4: 'Modules/battery/BatteryManager.idl',
Are you planning on moving the idl files out of WebCore.gypi eventually? If so,
ignore the other comment in this file.

https://codereview.chromium.org/14110002/diff/1/Source/WebKit/chromium/WebKit...
File Source/WebKit/chromium/WebKit.gyp (right):

https://codereview.chromium.org/14110002/diff/1/Source/WebKit/chromium/WebKit...
Source/WebKit/chromium/WebKit.gyp:588: '../../bindings/bindings.gyp:bindings',
Is this needed? It looks like there's an unconditional dependency on this
further up in the file already.

https://codereview.chromium.org/14110002/diff/1/Source/bindings/.gitignore
File Source/bindings/.gitignore (left):

https://codereview.chromium.org/14110002/diff/1/Source/bindings/.gitignore#ol...
Source/bindings/.gitignore:6: *.xcodeproj*
xcodeproj too, if someone feels like building with xcode (not less likely than
building with msvs :-P)

https://codereview.chromium.org/14110002/diff/1/Source/bindings/bindings.gyp
File Source/bindings/bindings.gyp (right):

https://codereview.chromium.org/14110002/diff/1/Source/bindings/bindings.gyp#...
Source/bindings/bindings.gyp:32: 'includes': [
Do you want '../../WebKit/chromium/WinPrecompile.gypi', too?

https://codereview.chromium.org/14110002/diff/1/Source/bindings/bindings.gyp#...
Source/bindings/bindings.gyp:51: # Bindings with custom Objective-C
implementations.
This comment might be out of date.

[Nico, 2013-04-11 06:02:52]

Oh, and the CL description could be a bit more explicit about the "more work"
that's to do. Maybe you could even have a tracking bug for your proposed
directory structure and mention that in a BUG= line.

[abarth-chromium, 2013-04-11 06:25:17]

On 2013/04/11 06:02:52, Nico wrote:
> Oh, and the CL description could be a bit more explicit about the "more work"
> that's to do.

Will do.

> Maybe you could even have a tracking bug for your proposed
> directory structure and mention that in a BUG= line.

That's a good idea.  I'll file one and reference it from this CL before landing.

https://codereview.chromium.org/14110002/diff/1/Source/WebCore/WebCore.gyp/We...
File Source/WebCore/WebCore.gyp/WebCore.gyp (left):

https://codereview.chromium.org/14110002/diff/1/Source/WebCore/WebCore.gyp/We...
Source/WebCore/WebCore.gyp/WebCore.gyp:2084: 'webcore_bindings',
On 2013/04/11 05:56:37, Nico wrote:
> Why is this no longer needed?

Because the targets who depend on webcore now need to depend on bindings
explicitly.  The end-goal is for bindings to be a layer on top of webcore, not
something included in webcore.

https://codereview.chromium.org/14110002/diff/1/Source/WebCore/WebCore.gypi
File Source/WebCore/WebCore.gypi (right):

https://codereview.chromium.org/14110002/diff/1/Source/WebCore/WebCore.gypi#n...
Source/WebCore/WebCore.gypi:4: 'Modules/battery/BatteryManager.idl',
On 2013/04/11 05:56:37, Nico wrote:
> Are you planning on moving the idl files out of WebCore.gypi eventually? If
so,
> ignore the other comment in this file.

I haven't worked that out entirely.  My current thinking is that webcore and
modules will export a list of IDL files so that the OWNERS of those modules can
manage their list of IDL files.  The bindings layer will consume those lists and
generate code from them.

https://codereview.chromium.org/14110002/diff/1/Source/WebKit/chromium/WebKit...
File Source/WebKit/chromium/WebKit.gyp (right):

https://codereview.chromium.org/14110002/diff/1/Source/WebKit/chromium/WebKit...
Source/WebKit/chromium/WebKit.gyp:588: '../../bindings/bindings.gyp:bindings',
On 2013/04/11 05:56:37, Nico wrote:
> Is this needed? It looks like there's an unconditional dependency on this
> further up in the file already.

I don't think it's needed, but I kept it for the time being.  As part of this
process, I'm going to clean up the whole build system.  At that time, I'll
rationalize all of these sorts of things.

https://codereview.chromium.org/14110002/diff/1/Source/bindings/.gitignore
File Source/bindings/.gitignore (left):

https://codereview.chromium.org/14110002/diff/1/Source/bindings/.gitignore#ol...
Source/bindings/.gitignore:6: *.xcodeproj*
On 2013/04/11 05:56:37, Nico wrote:
> xcodeproj too, if someone feels like building with xcode (not less likely than
> building with msvs :-P)

Will add.  (Note: This diff is just fro a random other gitignore file via the
magic of git.)

https://codereview.chromium.org/14110002/diff/1/Source/bindings/bindings.gyp
File Source/bindings/bindings.gyp (right):

https://codereview.chromium.org/14110002/diff/1/Source/bindings/bindings.gyp#...
Source/bindings/bindings.gyp:32: 'includes': [
On 2013/04/11 05:56:37, Nico wrote:
> Do you want '../../WebKit/chromium/WinPrecompile.gypi', too?

Yes, sorry.  I missed that.

https://codereview.chromium.org/14110002/diff/1/Source/bindings/bindings.gyp#...
Source/bindings/bindings.gyp:51: # Bindings with custom Objective-C
implementations.
On 2013/04/11 05:56:37, Nico wrote:
> This comment might be out of date.

Yeah.  At this point, it probably makes sense to remove these files from the
GYPI (or maybe add include them commented out).

[abarth-chromium, 2013-04-11 06:25:37]

Thanks for the review!

[commit-bot: I haz the power, 2013-04-11 06:51:17]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/abarth@chromium.org/14110002/11001

[commit-bot: I haz the power, 2013-04-11 07:14:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/abarth@chromium.org/14110002/2013

[abarth-chromium, 2013-04-11 07:22:19]

Committed patchset #3 manually as r148156 (presubmit successful).

[commit-bot: I haz the power, 2013-04-11 19:28:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/abarth@chromium.org/14110002/21001

[commit-bot: I haz the power, 2013-04-11 20:08:50]

Retried try job too often on linux_layout_rel for step(s) webkit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_layo...

[commit-bot: I haz the power, 2013-04-11 20:23:04]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/abarth@chromium.org/14110002/21001

[commit-bot: I haz the power, 2013-04-11 20:45:23]

Change committed as 148223

[abarth-chromium, 2013-04-12 17:26:56]

Note: I ran win tryjobs also:

http://build.chromium.org/p/tryserver.chromium/builders/win_rel/builds/134351
http://build.chromium.org/p/tryserver.chromium/builders/win/builds/64153

[abarth-chromium, 2013-04-12 17:36:29]

Committed patchset #5 manually as r148297 (presubmit successful).

[Julien - ping for review, 2013-04-15 18:17:55]

This change was reverted in https://codereview.chromium.org/14122012

[abarth-chromium, 2013-04-19 21:07:36]

@thakis: Do you want to look at this CL again?  I've reworked it substantially
since you last reviewed it.  The major difference is that I've factored a
derived_sources.gyp files out from both core.gyp and bindings.gyp.  The
derived_sources.gyp files are responsible for creating new source files (but not
building them).  I did this so that core.gyp:webcore_prerequisites can depend on
bindings/derived_sources.gyp (which in turn depends on
core/derived_sources.gyp).

Eventually, we'll want to clean up the dependencies here has not have core
depend on bindings, but that's going to be a bit more work.  :)

[Nico, 2013-04-20 04:50:54]

This still lgtm. I haven't looked through the dependencies in detail.

Unless you have data that shows that it doesn't help compile performance, I'd
keep the prefix header thing around though. (GCC_PRECOMPILE_PREFIX_HEADER is set
to YES via build/common.gypi).

https://codereview.chromium.org/14110002/diff/44001/Source/bindings/bindings.gyp
File Source/bindings/bindings.gyp (left):

https://codereview.chromium.org/14110002/diff/44001/Source/bindings/bindings....
Source/bindings/bindings.gyp:317: 'GCC_PREFIX_HEADER':
'../core/WebCorePrefix.h',
Last I measured, this made the build much faster. Is that no longer true?

https://codereview.chromium.org/14110002/diff/44001/Source/bindings/bindings....
Source/bindings/bindings.gyp:338: ],
From what I can tell, we don't actually use this anywhere. Maybe it can be
removed from config.gyp too.

https://codereview.chromium.org/14110002/diff/44001/Source/core/core.gyp/deri...
File Source/core/core.gyp/derived_sources.gyp (right):

https://codereview.chromium.org/14110002/diff/44001/Source/core/core.gyp/deri...
Source/core/core.gyp/derived_sources.gyp:67: 'target_name':
'core_derived_sources',
gen_derived_sources? make_derived_sources?

[abarth-chromium, 2013-04-20 16:35:59]

https://codereview.chromium.org/14110002/diff/44001/Source/bindings/bindings.gyp
File Source/bindings/bindings.gyp (left):

https://codereview.chromium.org/14110002/diff/44001/Source/bindings/bindings....
Source/bindings/bindings.gyp:317: 'GCC_PREFIX_HEADER':
'../core/WebCorePrefix.h',
On 2013/04/20 04:50:54, Nico wrote:
> Last I measured, this made the build much faster. Is that no longer true?

Ok.  I'll keep it.  Thanks!

https://codereview.chromium.org/14110002/diff/44001/Source/bindings/bindings....
Source/bindings/bindings.gyp:338: ],
On 2013/04/20 04:50:54, Nico wrote:
> From what I can tell, we don't actually use this anywhere. Maybe it can be
> removed from config.gyp too.

I'll try that in a followup CL.

https://codereview.chromium.org/14110002/diff/44001/Source/core/core.gyp/deri...
File Source/core/core.gyp/derived_sources.gyp (right):

https://codereview.chromium.org/14110002/diff/44001/Source/core/core.gyp/deri...
Source/core/core.gyp/derived_sources.gyp:67: 'target_name':
'core_derived_sources',
On 2013/04/20 04:50:54, Nico wrote:
> gen_derived_sources? make_derived_sources?

I wasn't sure whether to use verbs or nouns in the target name.  It sounds like
you're ok with verbs for targets that "do" something.  I'll change this to
make_derived_sources.

Is it ok to use the same target name in different GYP files?

[commit-bot: I haz the power, 2013-04-21 01:24:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/abarth@chromium.org/14110002/58001

[Nico, 2013-04-21 01:28:08]

https://codereview.chromium.org/14110002/diff/44001/Source/core/core.gyp/deri...
File Source/core/core.gyp/derived_sources.gyp (right):

https://codereview.chromium.org/14110002/diff/44001/Source/core/core.gyp/deri...
Source/core/core.gyp/derived_sources.gyp:67: 'target_name':
'core_derived_sources',
On 2013/04/20 16:36:00, abarth wrote:
> On 2013/04/20 04:50:54, Nico wrote:
> > gen_derived_sources? make_derived_sources?
> 
> I wasn't sure whether to use verbs or nouns in the target name.  It sounds
like
> you're ok with verbs for targets that "do" something.  I'll change this to
> make_derived_sources.
> 
> Is it ok to use the same target name in different GYP files?

Hm, at least the ninja generator generates an alias so that `ninja targetname`
builds target targetname. If two targets have the same name, I suppose that
stops working for at least one of the targets with the same name.

[abarth-chromium, 2013-04-21 01:29:18]

Ok.  I'll try to keep them relatively unique (at least within Blink).

[commit-bot: I haz the power, 2013-04-21 01:30:53]

Presubmit check for 14110002-58001 failed and returned exit status -2001.
The presubmit check was hung. It took 360.0 seconds to execute and the time
limit is 360.0 seconds.

INFO:root:Found 8 file(s).

[abarth-chromium, 2013-04-21 01:33:04]

I wonder why presubmit failed:

abarth@abarth3:/src/blink/src/third_party/WebKit$ git cl presubmit
Loaded authentication cookies from
/usr/local/google/home/abarth/.codereview_upload_cookies
Running presubmit commit checks ...

** Presubmit Messages **
It looks like you have not configured your subversion config file or it is not
up-to-date.
Please look at http://dev.chromium.org/developers/coding-style to
configure your subversion configuration file. This enables automatic
properties to simplify the project maintenance.
Pro-tip: just download and install
http://src.chromium.org/viewvc/chrome/trunk/tools/build/slave/config


Presubmit checks took 1.9s to calculate.

Presubmit checks passed.

[abarth-chromium, 2013-04-21 01:35:28]

Committed patchset #9 manually as r148784 (presubmit successful).

[blois, 2013-05-28 21:03:42]

https://codereview.chromium.org/14110002/diff/58001/Source/core/core.gypi
File Source/core/core.gypi (left):

https://codereview.chromium.org/14110002/diff/58001/Source/core/core.gypi#old...
Source/core/core.gypi:466: 'svg/SVGTransformable.idl',
I was curious about the removal of these- the IDL files are still present and
these types are still referenced from other IDL files. Are these in the process
of going away?

[abarth-chromium, 2013-05-28 21:06:36]

On 2013/05/28 21:03:42, blois wrote:
> https://codereview.chromium.org/14110002/diff/58001/Source/core/core.gypi
> File Source/core/core.gypi (left):
> 
>
https://codereview.chromium.org/14110002/diff/58001/Source/core/core.gypi#old...
> Source/core/core.gypi:466: 'svg/SVGTransformable.idl',
> I was curious about the removal of these- the IDL files are still present and
> these types are still referenced from other IDL files. Are these in the
process
> of going away?

Nope.  They were just never fed through the IDL compiler directly.  They're
abstract interfaces.