[Webkit-unassigned] [Bug 230735] Add a module map file for PrivateFrameworks/WebKitLegacy

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Oct 22 09:34:52 PDT 2021


https://bugs.webkit.org/show_bug.cgi?id=230735

--- Comment #21 from David Kilzer (:ddkilzer) <ddkilzer at webkit.org> ---
Comment on attachment 441851
  --> https://bugs.webkit.org/attachment.cgi?id=441851
Patch

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

>>> Source/WebCore/platform/ios/WebItemProviderPasteboard.h:-30
>>> -struct CGSize;
>> 
>> Why not put the #Import inside #if TARGET_OS_IOS/#endif?
> 
> It needs to be outside because that's what's pulling in TargetConditionals and defining TARGET_OS_IOS.

Okay, then why not just import <TargetConditions.h> instead and leave `struct CGSize` unchanged?

The reason we avoided including framework headers was to improve compile times, so this kind of change will undo that work.

I'd really rather see <TargetConditionals.h> imported instead.

>>> Source/WebKitLegacy/mac/DOM/WebDOMOperationsPrivate.h:31
>>>  #import <JavaScriptCore/JSBase.h>
>> 
>> The header order should probably be this (since we include the non-private header first?  Or does that give a check-webkit-style error?
>> 
>> #import <WebKitLegacy/WebDOMOperations.h>
>> #import <Foundation/Foundation.h>
>> #import <JavaScriptCore/JSBase.h>
> 
> Yeah, check-webkit-style said no.

That's probably a bug in check-webkit-style.  You don't have to fix it--I'm just noting it for reference.

>>>> Source/WebKitLegacy/mac/Misc/WebDownload.h:40
>>>>  #import <WebKitLegacy/NSURLDownloadSPI.h>
>>> 
>>> Both WebDownload.h and NSURLDownloadSPI.h are marked as Private headers, so we should be able to replace all of this with just:
>>> 
>>> #import <WebKitLegacy/NSURLDownloadSPI.h>
>>> 
>>> Since that has al the same logic as this block of macros.
>> 
>> I did that in one version of this and I'm trying to remember why I didn't leave it that way. I thought someone had told me to not do it like that but I don't see that comment either. Let me try and see what happens.
> 
> Oh now I remember. WebDownload.h is a public header in WebKit so it can't unconditionally import NSURLDownloadSPI.h because that's a private header. (That's going to be a problem later when WebKit gets fully modularized...)

Ah, thanks for the reminder.  It's weird that it's marked Private in the Xcode project, though?!

$ grep "WebDownload.h in Headers" Source/WebKitLegacy/WebKitLegacy.xcodeproj/project.pbxproj 
                939810770824BF01008DF038 /* WebDownload.h in Headers */ = {isa = PBXBuildFile; fileRef = 6578F5DE045F817400000128 /* WebDownload.h */; settings = {ATTRIBUTES = (Private, ); }; };
                                939810770824BF01008DF038 /* WebDownload.h in Headers */,

>>> Source/WebKitLegacy/mac/Storage/WebDatabaseQuotaManager.h:27
>>> +#import <objc/NSObject.h>
>> 
>> Why <objc/NSObject.h> instead of <Foundation/NSObject.h>?
> 
> Just because it didn't use anything from Foundation. It's unintuitively worse for build performance to import <Foundation/NSObject.h> than it is to import <Foundation/Foundation.h>, but do you want me to switch all these to <Foundation/Foundation.h>?

Ah, okay, as long as <objc/NSObject.h> is a public header, this seems fine as it aligns with the goal of not including framework headers if not needed.

Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211022/a2bfef25/attachment.htm>


More information about the webkit-unassigned mailing list