<html>
    <head>
      <base href="https://bugs.webkit.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [XCBuild] WTF's headers are copied via a script and are invisible to the build system"
   href="https://bugs.webkit.org/show_bug.cgi?id=235744#c8">Comment # 8</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [XCBuild] WTF's headers are copied via a script and are invisible to the build system"
   href="https://bugs.webkit.org/show_bug.cgi?id=235744">bug 235744</a>
              from <span class="vcard"><a class="email" href="mailto:emw@apple.com" title="Elliott Williams <emw@apple.com>"> <span class="fn">Elliott Williams</span></a>
</span></b>
        <pre>(In reply to Alexey Proskuryakov from <a href="show_bug.cgi?id=235744#c7">comment #7</a>)
<span class="quote">> > 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?</span >

See <a href="rdar://88293015">rdar://88293015</a> and <a href="rdar://88293050">rdar://88293050</a>.

<span class="quote">> What will WebKit engineers need to know about this approach when adding or
> removing WTF headers?</span >

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.


<span class="quote">> I wonder if flattening the hierarchy would be a better solution for now.
> That would require webkit-dev discussion if proposed, I think.</span >

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:

    /usr/local/include/wtf/win/SoftLinking.h
    /usr/local/include/wtf/spi/darwin/ProcessMemoryFootprint.h
    /usr/local/include/wtf/cocoa/SoftLinking.h
    /usr/local/include/wtf/linux/ProcessMemoryFootprint.h
    /usr/local/include/wtf/SoftLinking.h


<span class="quote">> > 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?</span >

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.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>