Bug 135819 – progress towards building WebCore with CMake on Mac

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Alex Christensen]

The ObjC bindings have a few things that are different than other bindings.  There are also a few quirks I've found.

[Alex Christensen]

Created attachment 236464 [details]
Patch

[Brent Fulgham]

Comment on attachment 236464 [details]
Patch

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

I don't think this is quite right, since it breaks an existing port that relies on CMake for its builds. Otherwise I think the general approach is good.

> Source/WebCore/CMakeLists.txt:-178
> -

Can these just be commented out with a FIXME(Bug ###) comment?

> Source/WebCore/PlatformMac.cmake:-146
> -    platform/mac/WebCoreView.m

Where did this go? Do we not have this file anymore?

> Source/WebCore/PlatformMac.cmake:-166
> -    platform/network/cf/ProtectionSpaceCFNet.cpp

Ditto.

> Source/WebCore/PlatformMac.cmake:-204
> -    plugins/mac/PluginViewMac.mm

Were these removed?

> Source/WebCore/bindings/scripts/CodeGeneratorObjC.pm:384
> +    die if $fatalError && $className ne "DOMAbstractView"; # ObjCCustomImplementation doesn't work with CMake right now.

Can you make this a FIXME(Bug XXX) comment, please?

> Source/cmake/OptionsMac.cmake:212
> +WEBKIT_OPTION_DEFAULT_PORT_VALUE(ENABLE_IOS_AIRPLAY_iphonesimulator OFF)

You should have a FIXME(Bug XXX) here to remind you to turn these back on.

> Source/cmake/WebKitMacros.cmake:37
> +macro(GENERATE_BINDINGS _output_source _input_files _base_dir _idl_includes _features _destination _prefix _generator _extension _idl_attributes_file)

This is causing the EFL build to fail. You need to add the 'cpp' target to those CMake files.

[Alex Christensen]

Created attachment 236469 [details]
Patch

[Alex Christensen]

(In reply to comment #2)
> (From update of attachment 236464 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=236464&action=review
> 
> I don't think this is quite right, since it breaks an existing port that relies on CMake for its builds. Otherwise I think the general approach is good.
> 
> > Source/WebCore/CMakeLists.txt:-178
> > -
> 
> Can these just be commented out with a FIXME(Bug ###) comment?
Will do, once I see the EWS response to this patch.
> 
> > Source/WebCore/PlatformMac.cmake:-146
> > -    platform/mac/WebCoreView.m
> 
> Where did this go? Do we not have this file anymore?
It doesn't know what to do with .m files right now.  I was removing it to get other things to compile.  I'll get rid of this change.
> 
> > Source/WebCore/PlatformMac.cmake:-166
> > -    platform/network/cf/ProtectionSpaceCFNet.cpp
> 
> Ditto.
> 
> > Source/WebCore/PlatformMac.cmake:-204
> > -    plugins/mac/PluginViewMac.mm
> 
> Were these removed?
They aren't in the mac build any more.  Maybe. I don't know what they are.

[Alex Christensen]

Created attachment 236475 [details]
Patch

[Alex Christensen]

Created attachment 236476 [details]
Patch

[Alex Christensen]

I think plugins/mac is dead code.  I'll remove it in a separate patch.
ProtectionSpaceCFNet.cpp is only used in the AppleWin port.  I had added it to the Mac build accidentally with the other CF files.

[Carlos Garcia Campos]

Comment on attachment 236476 [details]
Patch

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

> Source/WebCore/bindings/scripts/CodeGeneratorObjC.pm:253
>      my $fileName = "WebCore/bindings/objc/PublicDOMInterfaces.h";
> +    if (!-e $fileName) {
> +        # CMake looks in the WebCore directory.
> +        $fileName = "bindings/objc/PublicDOMInterfaces.h"
> +    }

You could use the same code in both cases by finding the bindings dir using:

use FindBin;

my $bindingsDir = dirname($FindBin::Bin);
my $fileName = "$bindingsDir/objc/PublicDOMInterfaces.h";

That's what we do in CodeGeneratorGObject.pm

[Alex Christensen]

Created attachment 236545 [details]
Patch

[Alex Christensen]

(In reply to comment #8)
> (From update of attachment 236476 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=236476&action=review
> 
> > Source/WebCore/bindings/scripts/CodeGeneratorObjC.pm:253
> >      my $fileName = "WebCore/bindings/objc/PublicDOMInterfaces.h";
> > +    if (!-e $fileName) {
> > +        # CMake looks in the WebCore directory.
> > +        $fileName = "bindings/objc/PublicDOMInterfaces.h"
> > +    }
> 
> You could use the same code in both cases by finding the bindings dir using:
> 
> use FindBin;
> 
> my $bindingsDir = dirname($FindBin::Bin);
> my $fileName = "$bindingsDir/objc/PublicDOMInterfaces.h";
> 
> That's what we do in CodeGeneratorGObject.pm
Done.

I think the Mac WK2 test failures have nothing to do with this.

[Laszlo Gombos]

Comment on attachment 236545 [details]
Patch

LGTM - as it seems the Gamepad code is not yet enable in any existing cmake-based ports anyways, so this will not cause a regression.

[Alex Christensen]

http://trac.webkit.org/changeset/172540