WEBKIT_MAKE_FORWARDING_HEADERS should just copy files and not do anything else to the target framework. Dependencies between the headers should be explicitly set. It is currently adding a dependency on the target framework. This shouldn't be the case. Also this macro can be used to copy over other file types, such as scripts, that are currently just copied with file(COPY). If any of those files change then this isn't going to propagate which is a problem.
Created attachment 368743 [details] Patch
Created attachment 368746 [details] Patch Hopefully fix jsc only builds.
Comment on attachment 368746 [details] Patch Clearing flags on attachment: 368746 Committed r244881: <https://trac.webkit.org/changeset/244881>
All reviewed patches have been landed. Closing bug.
Comment on attachment 368746 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=368746&action=review > Source/JavaScriptCore/CMakeLists.txt:1308 > +add_dependencies(JavaScriptCorePrivateFrameworkHeaders JavaScriptCore) Any reason why the dependency is reversed for JavaScriptCorePrivateFrameworkHeaders? It's causing build failures for me on WPE, where CustomGlobalObjectClassTest.c from the testapi target is trying to include the JSObjectRefPrivate.h forwarding header which doesn't (yet?) exist. Switching the targets fixes it for me.
Re-opened since this is blocked by bug 197559
(In reply to WebKit Commit Bot from comment #6) > Re-opened since this is blocked by bug 197559 Rolling out because this breaks 3 EWS bots (jsc-armv7-ews, jsc-mips-ews and jsc-i386-ews) and would likely start to break buildbots once we do a clean build. The change suggested by Žan seems to fix it, but I don't know whether this would have ill side effects on other platforms, hence the rollout to give time to Dom to figure this out.
(In reply to Zan Dobersek from comment #5) > Comment on attachment 368746 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=368746&action=review > > > Source/JavaScriptCore/CMakeLists.txt:1308 > > +add_dependencies(JavaScriptCorePrivateFrameworkHeaders JavaScriptCore) > > Any reason why the dependency is reversed for > JavaScriptCorePrivateFrameworkHeaders? > It's causing build failures for me on WPE, where > CustomGlobalObjectClassTest.c from the testapi target is trying to include > the JSObjectRefPrivate.h forwarding header which doesn't (yet?) exist. > > Switching the targets fixes it for me. I see the problem here but I'm not sure what the fix is so adding some JSC folks into the mix. If you look in Source/JavaScriptCore/API/tests/CustomGlobalObjectClassTest.c theres #include <JavaScriptCore/JSObjectRefPrivate.h> If you look in ExecutionTimeLimitTest.cpp there's #include "JSObjectRefPrivate.h" I see a bunch of these inconsistencies in there. So yes that's why you saw this build failure. JSC folks I would assume that testapi should just be using <JavaScriptCore/*.h> for includes. Is that a fair assessment? Also should any of the other text executables and JSC itself be using <JavaScriptCore/*.h> style? I'm happy to fix this before relanding this patch.