[Webkit-unassigned] [Bug 182757] [CMake][Ninja] Fails to compile TestWebCore due to missing WebCore's derived headers

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=182757

--- Comment #10 from Don Olmstead <don.olmstead at sony.com> ---
Comment on attachment 334072
  --> https://bugs.webkit.org/attachment.cgi?id=334072
WIP Patch

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

Ok I think this is better than that last patch. I don't see rebuilds in Visual Studio.

Fujii and Konstantin could you take a look to see if what I'm doing is sane within CMake land?

> Source/JavaScriptCore/CMakeLists.txt:15
> +    "${CMAKE_BINARY_DIR}/JavaScriptCore.framework/Headers"
> +    "${CMAKE_BINARY_DIR}/JavaScriptCore.framework/PrivateHeaders"

This follows along with how Apple builds operate.

Stuff in PrivateHeaders does a #include <JavaScriptCore/Foo.h> so this would likely catch any compile errors. Also LLInt needs these headers installed.

> Source/JavaScriptCore/CMakeLists.txt:1187
> +    PRIVATE_HEADERS ${JavaScriptCore_PRIVATE_FRAMEWORK_HEADERS} ${JavaScriptCore_HEADERS}

All the DerivedSources seem to be in ${JavaScriptCore_HEADERS}. It feels like the JSC CMake stuff is in better shape than WebCore. I feel like we might want to do something similar in WebCore with Derived Sources.

> Source/JavaScriptCore/CMakeLists.txt:1195
> +add_dependencies(LLIntOffsetsExtractor JavaScriptCoreFrameworkHeaders)

By splitting into public and private we can do this. Actually I think the only reason we weren't hitting a compile error here is that the copying just happens to complete before this is hit.

> Source/cmake/WebKitMacros.cmake:265
> +            add_custom_command(TARGET ${framework} PRE_LINK

So this moves the DerivedSources to being copied within the original ${framework} as a PRE_LINK step which happens before a POST_BUILD. Seems like a safe bet that things are going to be ok at this point.

I need to see how things work with WebCore to really determine if this will work across the board.

It seems to not cause rebuilds within Visual Studio so I think it solves things. Placing them within PrivateFrameworkHeaders causes the rebuilds in visual studio.

> Source/cmake/WebKitMacros.cmake:283
> +    #add_dependencies(${framework}PrivateFrameworkHeaders ${framework})

I'm not listing any dependencies for either of the *FrameworkHeaders projects. This should all be listed in required projects. Hopefully it will mean that we don't end up with a really serialized clean build.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180216/46fc2b37/attachment-0001.html>