Re-export Skia defines from content_browser.gypi.

Re-export Skia defines from content_browser.gypi.

Doing a code search for "file:src/content/public/browser.*\.h skia" shows
six public headers which are including Skia headers. These Skia headers
require that the defines exported from skia.gyp be available. Currently
the build is getting away with this by accident, but some proposed
changes to some Skia headers will cause this to fail. Correct this by
re-exporting the skia.gyp settings.

[bungeman-chromium, 2013-10-11 14:40:18]

Any owner willing to take a look? I'd like to avoid having skia.gyp use
all_dependent_settings to get around this, as that will push quite a few
settings to a number of targets which don't need them.

[jam, 2013-10-11 14:58:52]

On 2013/10/11 14:40:18, bungeman2 wrote:
> Any owner willing to take a look? I'd like to avoid having skia.gyp use
> all_dependent_settings to get around this, as that will push quite a few
> settings to a number of targets which don't need them.

what is the harm in pushing settings to targets that don't need them?

it seems a maintenance burden that every time a module includes a skia header in
its public headers, they have to know this magic setting to add to their gyp
files.

[bungeman-chromium, 2013-10-11 15:07:02]

I am rather frustrated by the lack of interest in having clean build files. I
will use all_dependent_settings and slow down gyp generation.

[jam, 2013-10-14 20:38:32]

On 2013/10/11 15:07:02, bungeman2 wrote:
> I am rather frustrated by the lack of interest in having clean build files.

That is a bit of a mischaracterization. There are tradeoffs in terms of
maintenance burden.

For example, if this gets added to content's gyp, then what happens if there are
no more includes of skia code in content/public, then practically we'll never
notice and remove that entry and it's the same issue that you describe (the
settings are pushed to modules that don't need them). Looking at the existing
headers, it seems that the only one that's actually needed is the SkColor.h,
which is also used in src/ui/gfx. gfx is an even lower level module than
content, which many other modules depend on. So if the skia settings are pushed
to all users of ui, isn't that pretty much every module?

> I will use all_dependent_settings and slow down gyp generation.

[brettw, 2013-10-22 17:16:42]

I noticed this go by so I thought I would comment since I've been doing a lot of
thinking about this as part of the new build.

There are two schools of thought about whether this kind of thing should be
"all" or "direct." The direct school is basically like private inheritance in
C++ and saying that you shouldn't have any more flags than necessary. The all
school says that this is too difficult to maintain. We do both randomly in
Chrome.

My opinion is that the "direct" is better, BUT that it's not practical until we
have better dependency management. Currently you can get really weird and
difficult-to-track-down compilation errors, and there's not a lot of
infrastructure to help. This is what John is mainly concerned with, I think.

Ideally our dependency management system would have some notion of "public"
headers and we could check that if you include a header that you have the proper
permissions and dependencies to do it. Google3 has some things along these
lines. Until we have something like this, I don't have a strong opinion about
what the best way to do this.