Bug 143785

Summary: More progress towards CMake on Mac
Product: WebKit Reporter: Alex Christensen <achristensen>
Component: WebKit Misc.Assignee: Alex Christensen <achristensen>
Status: RESOLVED FIXED    
Severity: Normal CC: ossy
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch ossy: review+

Description Alex Christensen 2015-04-15 10:30:27 PDT
I'm getting pretty close to compiling and linking WK1 and WK2.  

There is going to need to be either a list of objc bindings to add or remove, because not all objc bindings that are generated are used or even compile.  There are probably some quirks left to iron out in this list, but it's a huge step in the right direction.
Comment 1 Alex Christensen 2015-04-15 10:35:30 PDT
Created attachment 250821 [details]
Patch
Comment 2 Alex Christensen 2015-04-15 10:49:25 PDT
Created attachment 250823 [details]
Patch
Comment 3 Csaba Osztrogonác 2015-04-15 13:21:11 PDT
Comment on attachment 250823 [details]
Patch

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

> Source/WebKit/mac/WebView/WebPDFDocumentExtras.mm:38
> +#ifdef BUILDING_WITH_CMAKE
> +#import <PDFDocument.h>
> +#else
>  #import <PDFKit/PDFDocument.h>
>  #endif
> +#endif

?

> Source/WebKit/mac/WebView/WebPDFView.mm:73
> +#ifdef BUILDING_WITH_CMAKE
> +#import <PDFKit.h>
> +#else
> +#import <PDFKit/PDFKit.h>
> +#endif

Why the import path is different with cmake?
Comment 4 Chris Dumez 2015-04-15 13:25:09 PDT
Comment on attachment 250823 [details]
Patch

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

>> Source/WebKit/mac/WebView/WebPDFDocumentExtras.mm:38
>> +#endif
> 
> ?

I agree this should be addressed differently.

>> Source/WebKit/mac/WebView/WebPDFView.mm:73
>> +#endif
> 
> Why the import path is different with cmake?

Ditto.
Comment 5 Alex Christensen 2015-04-15 13:32:09 PDT
(In reply to comment #3)
> Why the import path is different with cmake?
CMake couldn't find the PDFKit.framework inside of the umbrella framework Quartz.framework, so I taught it how to find the binary and headers.  We do similar things when including ShaderLang.h.  Would you be ok with me putting it in as-is and if it becomes a problem we can fix it somehow?
Comment 6 Alex Christensen 2015-04-15 13:42:06 PDT
Comment on attachment 250823 [details]
Patch

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

> Source/WebKit/PlatformMac.cmake:19
> +find_library(PDFKIT_FRAMEWORK PDFKit HINTS ${QUARTZ_LIBRARY}/Versions/*/Frameworks)
> +find_path(PDFKIT_INCLUDE_DIRECTORY PDFKit.h HINTS ${PDFKIT_FRAMEWORK}/Versions/*/Headers)

After reading http://www.cmake.org/cmake/help/v3.0/command/find_package.html I determined that this was the best way to find frameworks in umbrella frameworks, which are not found by default CMake.
Comment 7 Alex Christensen 2015-04-15 15:47:38 PDT
Committed without the questionable #ifdef BUILDING_WITH_CMAKE to http://trac.webkit.org/changeset/182865