Bug 29753 – DerivedSources.make broken for non-Mac targets

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Steve Falkenburg]

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

[David Kilzer (:ddkilzer)]

Which revision did this break in?  Was it r48609?

[David Kilzer (:ddkilzer)]

(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>

[Mark Rowe (bdash)]

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.

[David Kilzer (:ddkilzer)]

(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.

[Mark Rowe (bdash)]

Correct.

[David Kilzer (:ddkilzer)]

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?

[David Kilzer (:ddkilzer)]

Created attachment 40159 [details]
Part 1 Patch v1

[Greg Bolsinga]

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.

[David Kilzer (:ddkilzer)]

(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.

[David Kilzer (:ddkilzer)]

Committed r48784: <http://trac.webkit.org/changeset/48784>

[David Kilzer (:ddkilzer)]

Comment on attachment 40159 [details]
Part 1 Patch v1

Clearing darin's r+ flag.

[David Kilzer (:ddkilzer)]

Created attachment 40168 [details]
Part 2 Patch v1

[David Kilzer (:ddkilzer)]

Committed r48795: <http://trac.webkit.org/changeset/48795>

[David Kilzer (:ddkilzer)]

GTK build fix:

Committed r48796: <http://trac.webkit.org/changeset/48796>