RESOLVED FIXED147723
[GTK] Fix build issue related to the generated WebKitFontFamilyNames.h
https://bugs.webkit.org/show_bug.cgi?id=147723
Summary [GTK] Fix build issue related to the generated WebKitFontFamilyNames.h
Csaba Osztrogonác
Reported 2015-08-05 22:54:09 PDT
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.
Attachments
Patch (1.64 KB, patch)
2015-08-06 14:05 PDT, Alex Christensen
no flags
Csaba Osztrogonác
Comment 1 2015-08-05 22:57:30 PDT
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
Comment 2 2015-08-05 23:00:48 PDT
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
Comment 3 2015-08-05 23:10:33 PDT
+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
Comment 4 2015-08-06 00:59:38 PDT
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
Comment 5 2015-08-06 04:43:12 PDT
(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
Comment 6 2015-08-06 14:05:41 PDT
Alex Christensen
Comment 7 2015-08-06 14:08:17 PDT
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
Comment 8 2015-08-06 16:59:56 PDT
This seems to prevent me from running into the same issue on the partially-complete CMake build on mac.
Gyuyoung Kim
Comment 9 2015-08-06 19:58:50 PDT
Comment on attachment 258394 [details] Patch EFL port also has same build error when building it from scratch.
WebKit Commit Bot
Comment 10 2015-08-06 22:15:26 PDT
Comment on attachment 258394 [details] Patch Clearing flags on attachment: 258394 Committed r188116: <http://trac.webkit.org/changeset/188116>
WebKit Commit Bot
Comment 11 2015-08-06 22:15:32 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.