[GTK] Fix build issue related to the generated WebKitFontFamilyNames.h

[Csaba Osztrogonác]

Now the build is broken on the GTK bot with the following error:

In file included from ../../Source/WebCore/testing/Internals.cpp:35:
In file included from ../../Source/WebCore/loader/cache/CachedResourceLoader.h:32:
In file included from ../../Source/WebCore/loader/cache/CachedResourceRequest.h:30:
In file included from ../../Source/WebCore/dom/Element.h:29:
In file included from ../../Source/WebCore/dom/Document.h:38:
In file included from ../../Source/WebCore/platform/graphics/FontSelector.h:29:
In file included from ../../Source/WebCore/platform/graphics/FontRanges.h:29:
In file included from ../../Source/WebCore/platform/graphics/Font.h:30:
In file included from ../../Source/WebCore/platform/graphics/FontPlatformData.h:27:
In file included from ../../Source/WebCore/platform/graphics/freetype/FontPlatformData.h:29:
In file included from ../../Source/WebCore/platform/graphics/FontCache.h:33:
../../Source/WebCore/platform/graphics/FontDescription.h:31:10: fatal error: 'WebKitFontFamilyNames.h' file not found
#include "WebKitFontFamilyNames.h"
         ^

The problem is that WebKitFontFamilyNames.h isn't yet generated,
so it must be a dependency problem in the cmake build sysytem.

I don't have time to work on this bug, I just reported to let you 
know and feel free to pick it up if you are interested in it.

[Csaba Osztrogonác]

First time we can noticed this clean build failure:
https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Build%29/builds/61040, because the build #61039 caused a fresh SVN checkout.

[Csaba Osztrogonác]

One more thing: It's strange that EFL doesn't have this build problem,
but this codes are in common cmake code path as far as I know.

[Csaba Osztrogonác]

+info: I checked the generated ninja file of GTK and EFL too and it 
seems that testing/MockCDM.cpp is the only one source file which has 
the WebKitFontFamilyNames.h dependency set on EFL. But no other cpp
has set this dependency. Maybe because they are added to 
WebCoreTestSupport_SOURCES and not to WebCore_SOURCES variable.

[Carlos Garcia Campos]

Looking at the log, it seems to me that r187997 could have introduced the issue, since it removes the WebCore dependency from a couple of targets.

[Xabier Rodríguez Calvar]

(In reply to comment #4)
> Looking at the log, it seems to me that r187997 could have introduced the
> issue, since it removes the WebCore dependency from a couple of targets.

It is definitely this revision, I bisected it.

[Alex Christensen]

Created attachment 258394 [details]
Patch

[Alex Christensen]

Sorry! Brent even commented about that line in WebCore/CMakeLists.txt. I guess EWS doesn't do clean builds, which is where this problem arises. My bad.

Does this patch fix it?

Also, is it really necessary to have a dependency on ${WEBCORE_DIR}/CMakeLists.txt inside of CMakeLists.txt?  It would save a lot of rebuilding time if that weren't there, but I'm not sure why it's there enough to remove it.

[Alex Christensen]

This seems to prevent me from running into the same issue on the partially-complete CMake build on mac.

[Gyuyoung Kim]

Comment on attachment 258394 [details]
Patch

EFL port also has same build error when building it from scratch.

[WebKit Commit Bot]

Comment on attachment 258394 [details]
Patch

Clearing flags on attachment: 258394

Committed r188116: <http://trac.webkit.org/changeset/188116>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.