[Webkit-unassigned] [Bug 235744] [XCBuild] WTF's headers are copied via a script and are invisible to the build system

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jan 31 14:12:32 PST 2022


--- Comment #8 from Elliott Williams <emw at apple.com> ---
(In reply to Alexey Proskuryakov from comment #7)
> > This approach is obtuse. But as far as I can tell, the best way to get what we need (native PbxCp tasks for each header) is to create one copy files build phase per header subdirectory.
> Indeed. Can you post radar numbers (without other details) of what will let
> us make it more elegant in the future?

See rdar://88293015 and rdar://88293050.

> What will WebKit engineers need to know about this approach when adding or
> removing WTF headers?

When adding headers to WTF:
- You must add it to WTF.xcodeproj (like you would for a source file).
- You must add it to the copy files phase which corresponds to the directory the header belongs to.
- If you don't, Xcode won't copy the header, and targets which import it will fail to build.

When removing headers to WTF:
- You must remove the header's file reference from WTF.xcodeproj (like you would for a source file).
- If you don't, Xcode will fail to build WTF.

> I wonder if flattening the hierarchy would be a better solution for now.
> That would require webkit-dev discussion if proposed, I think.

One thing that occurred to me while working on this is that I _thought_ WebKit's convention was to have flat header hierarchies. I don't want to stall XCBuild work on this too much, but if you think we could do it without opposition, it totally makes sense to me.

Note WTF has some headers with the same basename, so flattening the hierarchy would mean we'd need to rename them:


> > Source/WTF/WTF.xcodeproj/project.pbxproj:162
> > +		DD3DC85E27A4BF8E007E5B61 /* WeakHashSet.h in Headers */ = {isa = PBXBuildFile; fileRef = 9B67F3F12228D5310030DE9C /* WeakHashSet.h */; settings = {ATTRIBUTES = (Public, ); }; };
> Nothing in WTF is public API, is it OK for these headers to have the Public
> attribute?

I don't think it matters per se -- this distinction exists only because framework bundles have separate `Headers` and `PrivateHeaders` directories -- but I can switch to marking them "private" for semantic clarity.

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/20220131/a3e32b27/attachment-0001.htm>

More information about the webkit-unassigned mailing list