Bug 110498 – [GTK] Expose all dependencies to the gyp build

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Martin Robinson]

With the ease of adding new dependencies in mind, we should roll them into Configuration.gypi. This is a good moment to add all the dependencies from our configuration step as well. They're necessary to build WebCore.

[Martin Robinson]

Created attachment 189579 [details]
Patch

[Dirk Pranke]

Comment on attachment 189579 [details]
Patch

Doesn't this result in multiple copies of each dependency target in the sub-makefiles?

[Martin Robinson]

Comment on attachment 189579 [details]
Patch

It does seem to do that.

[Martin Robinson]

It seems like there are two options to avoid this. One is to continue to manage the dependency targets in two separate files again and the other is to also run Dependencies.gyp through the autoconf preprocessor.

[Dirk Pranke]

two separate files? can't you just list the dependencies in a one file?

I'm not sure I understand the comment about running Dependencies.gyp through the autoconf processor, though. I'm guessing that's probably related (and maybe does make sense).

Generally, we only put variable definitions and other settings in files that are passed in via -I, not actual targets (for the reason just cited, among others).

[Martin Robinson]

(In reply to comment #5)
> two separate files? can't you just list the dependencies in a one file?
> 
> I'm not sure I understand the comment about running Dependencies.gyp through the autoconf processor, though. I'm guessing that's probably related (and maybe does make sense).
> 
> Generally, we only put variable definitions and other settings in files that are passed in via -I, not actual targets (for the reason just cited, among others).

All the template fields in Configuration.gypi.in (looking like @FOO_CFLAGS@) are filled in during './configure' and the result is written to Configuration.gypi in the build directory. Since Configuration.gypi cannot contain targets in a sane way, we'll likely need to keep targets in a separate file -- Dependencies.gyp. I think that I chose to use the variables (<(FOO_CLFAGS) etc) directly because it would avoid having to add boilerplate across more than one file. There are some important benefits to using targets to represent dependencies, but it does increase the amount of boilerplate necessary to add the n+1.

[Dirk Pranke]

(In reply to comment #6)
> (In reply to comment #5)
> > two separate files? can't you just list the dependencies in a one file?
> > 
> > I'm not sure I understand the comment about running Dependencies.gyp through the autoconf processor, though. I'm guessing that's probably related (and maybe does make sense).
> > 
> > Generally, we only put variable definitions and other settings in files that are passed in via -I, not actual targets (for the reason just cited, among others).
> 
> All the template fields in Configuration.gypi.in (looking like @FOO_CFLAGS@) are filled in during './configure' and the result is written to Configuration.gypi in the build directory. Since Configuration.gypi cannot contain targets in a sane way, we'll likely need to keep targets in a separate file -- Dependencies.gyp. I think that I chose to use the variables (<(FOO_CLFAGS) etc) directly because it would avoid having to add boilerplate across more than one file. There are some important benefits to using targets to represent dependencies, but it does increase the amount of boilerplate necessary to add the n+1.

Ah, right, two files == configuration + dependencies.

[Martin Robinson]

Created attachment 189784 [details]
Patch

[Martin Robinson]

This is a simplified patch that just fills in the gaps in terms of dependencies.

[Dirk Pranke]

Comment on attachment 189784 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=189784&action=review

It does seem like generating Dependencies.gyp from a Dependencies.gyp.in might make things clearer and remove some of the duplication, but this is fine for now (and up to you).

> Source/WebKit/gtk/gyp/Dependencies.gyp:13
> +

nit: stylistically, we don't usually separate these blocks w/ blank lines.

[Martin Robinson]

Committed r143835: <http://trac.webkit.org/changeset/143835>

[Martin Robinson]

(In reply to comment #10)
> (From update of attachment 189784 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=189784&action=review
> 
> It does seem like generating Dependencies.gyp from a Dependencies.gyp.in might make things clearer and remove some of the duplication, but this is fine for now (and up to you).

Thanks for the review! It's a little tricky right now, because things processed by configure should really end up in the build directory. That means we'd need to have some extra variables in Configuration.gypi (itself in the build directory) so that we can get the proper path for inclusion.

> 
> > Source/WebKit/gtk/gyp/Dependencies.gyp:13
> > +
> 
> nit: stylistically, we don't usually separate these blocks w/ blank lines.

I've fixed this. :)