[PATCH] D123831: [POC][WIP] Use relative include in extract-api

Thu Apr 21 06:57:13 PDT 2022

dang added a comment.

In D123831#3459368 <https://reviews.llvm.org/D123831#3459368>, @ributzka wrote:

> In D123831#3458774 <https://reviews.llvm.org/D123831#3458774>, @dang wrote:
>
>> In D123831#3455048 <https://reviews.llvm.org/D123831#3455048>, @cishida wrote:
>>
>>>> we might not always want to transform an absolute path because the resulting relative include name might get remapped in a headermap, for example in test known_files_only_hmap.c. But how does it work with modules where we need relative includes? Is the setup in known_files_only_hmap even valid?
>>>
>>> I think, in most cases, this shouldn't matter because if the header path input doesn't match the location stored in the header map, they should still have the same source content. The same should be true with header search resolution with modules & vfsoverlay
>>
>> Agreed, I think it would be classified as a user error to remap to different source content via headermap.
>
> This is happening today in Xcode. Headers that are mapped from the DSTROOT back to the SRCROOT can be different, because they are not simply copied. Xcode also runs unifdef on them.

What do you mean? The headers in the DSTROOT don't have the ifdef? Either way, this shouldn't matter because the declarations we are processing would be the same across both versions of the header?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123831/new/

https://reviews.llvm.org/D123831