[webkit-reviews] review requested: [Bug 236683] [XCBuild] Use native build phases to copy PAL's headers : [Attachment 452123] Native PAL Headers via build rules

[bugzilla-daemon at webkit.org]

Elliott Williams <emw at apple.com> has asked  for review:
Bug 236683: [XCBuild] Use native build phases to copy PAL's headers
https://bugs.webkit.org/show_bug.cgi?id=236683

Attachment 452123: Native PAL Headers via build rules

https://bugs.webkit.org/attachment.cgi?id=452123&action=review




--- Comment #1 from Elliott Williams <emw at apple.com> ---
Created attachment 452123

  --> https://bugs.webkit.org/attachment.cgi?id=452123&action=review

Native PAL Headers via build rules

See the ChangeLog for more details, but I figured out a way to do nested
headers without adding a bunch of copy file phases, like was done for WTF. This
makes the project easier for devs to understand (all headers go in the same
phase), plus, PAL has more nested directories than WTF does.

The key idea is that if you know the *depth* of a nested header, you can use
build setting macros to produce its relative path. For example, given:

    PRIVATE_HEADERS_FOLDER_PATH = /usr/local/include/pal
    INPUT_FILE_DIR = Source/WebCore/PAL/pal/text
    INPUT_FILE_NAME = EncodingTables.h

the path for <pal/text/EncodingTables.h> is:

   
$(PRIVATE_HEADERS_FOLDER_PATH)/$(INPUT_FILE_DIR:dir:standardizepath:base)/$(INP
UT_FILE_NAME)

For deeper headers like <pal/crypto/tasn1/Utilities.h>, we give the last *two*
directory components:

   
$(PRIVATE_HEADERS_FOLDER_PATH)/$(INPUT_FILE_DIR:dir:standardizepath:dir:standar
dizepath:base)/$(INPUT_FILE_DIR:dir:standardizepath:base)/$(INPUT_FILE_NAME)

and so on.

These paths form the outputs of separate build rules which match each depth of
nested header we need.