[Webkit-unassigned] [Bug 236683] [XCBuild] Use native build phases to copy PAL's headers

[bugzilla-daemon at webkit.org]

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

Elliott Williams <emw at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #452123|                            |review?
              Flags|                            |

--- 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)/$(INPUT_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:standardizepath: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.

-- 
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/20220216/87dc6ce3/attachment.htm>