Bug 143785 - More progress towards CMake on Mac
Summary: More progress towards CMake on Mac
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alex Christensen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-15 10:30 PDT by Alex Christensen
Modified: 2015-04-15 15:47 PDT (History)
1 user (show)

See Also:


Attachments
Patch (28.50 KB, patch)
2015-04-15 10:35 PDT, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (27.60 KB, patch)
2015-04-15 10:49 PDT, Alex Christensen
ossy: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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