I get errors building DerivedSources.make in WebCore on Windows. The parameters passed to gcc for preprocessing aren't correct for non-Mac builds. In particular, since -F isn't supported, we don't pass it, but this means that gcc can't locate the headers needed to complete the compiles. Besides this, the path to WebCore should be specified as $(WebCore) to work on Windows (in the gcc commands). Here's the error output I see on Windows: ------ Build started: Project: WebCoreGenerated, Configuration: Release Win32 ------ Performing Makefile project actions /usr/bin/bash gcc: WebCore/ForwardingHeaders/wtf/Platform.h: No such file or directory gcc: no input files gcc: WebCore/ForwardingHeaders/wtf/Platform.h: No such file or directory gcc: no input files gcc: WebCore/ForwardingHeaders/wtf/Platform.h: No such file or directory gcc: no input files gcc: WebCore/ForwardingHeaders/wtf/Platform.h: No such file or directory gcc: no input files
Which revision did this break in? Was it r48609?
(In reply to comment #0) > In particular, since -F isn't supported, we don't pass it, but this means that > gcc can't locate the headers needed to complete the compiles. It appears that the -F issue was fixed in r48729: <http://trac.webkit.org/changeset/48729>
The -F change didn't achieve towards fixing other platforms. The fundamental issue here is that the manner in which we detect whether the macro is enabled only works on Mac, due to the search path only being set on Mac and the header file using a path that is not portable.
(In reply to comment #3) > The fundamental issue here is that the manner in which we detect whether the > macro is enabled only works on Mac, due to the search path only being set on > Mac and the header file using a path that is not portable. I guess we can't use $(WebCore)/../JavaScriptCore/wtf/Platform.h because we can't always assume that JavaScriptCore sources are sitting next to WebCore sources.
Correct.
So ENABLE_CONTEXT_MENUS, ENABLE_DRAG_SUPPORT and ENABLE_INSPECTOR are only used to determine which *.exp files to concatenate for the Mac platform, so those definitions may all be moved out of the common code path. That leaves ENABLE_ORIENTATION_EVENTS. It's required for both the *.exp file generation and the JS/ObjC code generation. One solution there would be to move it (back) to the FeatureDefines.xcconfig files (and related build files for other platforms) where it was in an earlier patch for Bug 29508. Is that acceptable?
Created attachment 40159 [details] Part 1 Patch v1
Dave, I would suggest we have ENABLE_DRAG_AND_DROP, ENABLE_INSPECTOR, and ENABLE_CONTEXT_MENUS always be on. See the non MacOS ENABLE_DASHBOARD_SUPPORT section. This is because testing really isn't even needed here. Nothing in Open Source will turn these off at the moment. We can just 'do the right thing' for iPhone as is being done for Mac OS now, in this makefile.
(In reply to comment #8) > Dave, I would suggest we have ENABLE_DRAG_AND_DROP, ENABLE_INSPECTOR, and > ENABLE_CONTEXT_MENUS always be on. See the non MacOS ENABLE_DASHBOARD_SUPPORT > section. The only reason that's needed is because ENABLE_DASHBOARD_SUPPORT is used for both WEBCORE_CSS_PROPERTY_NAMES and WEBCORE_EXPORT_DEPENDENCIES. Moving these tests to where they're used is consistent with the other *.exp file tests.
Committed r48784: <http://trac.webkit.org/changeset/48784>
Comment on attachment 40159 [details] Part 1 Patch v1 Clearing darin's r+ flag.
Created attachment 40168 [details] Part 2 Patch v1
Committed r48795: <http://trac.webkit.org/changeset/48795>
GTK build fix: Committed r48796: <http://trac.webkit.org/changeset/48796>