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

[Juergen Ributzka via Phabricator via cfe-commits]

ributzka added a comment.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123831