[foreign] RFR 8219653: jextract should search -I paths for header file(s)

[Sundararajan Athijegannathan]

Hi,

There is an important difference between native compiler and jextract. 
Primary input files for native compilers are .c/.cpp files whereas 
jextract accepts .h/.hpp files. For native packages installed in 
non-standard paths, user would have to specify the include path (prefix) 
twice once for -I and once as prefix of header input(s).

jextract passes absolute paths of the header files to clang - 
with/without the current change. When jextract generates a compound 
temp. header file, #includes in that file will specify absolute paths as 
well. So the confusion mentioned in stack overflow may not be applicable 
in jextract case.

-Sundar

On 25/02/19, 9:19 PM, Maurizio Cimadamore wrote:
> Not sure about this (sorry about sending you the wrong way in private 
> chat, I got your intention backwards!)
>
> First, this seems to diverge from what native compilers do:
>
> $ clang -I foo a.h
> clang: error: no such file or directory: 'a.h'```
>
> where:
>
> foo/
> ├── a.c
> ├── a.h
> ├── b.h
>
> Secondly, and more seriously, looking around, it seems that the 
> behavior with respect to including a file that is mentioned in two 
> include paths is unspecified.
>
> https://stackoverflow.com/questions/16832392/equal-header-file-in-different-include-paths 
>
>
> This would create issues - because with your patch, jextract is 
> essentially assuming that 'foo.h' means: X/foo.h, where X is the first 
> include path for which X/foo.h exists. But in reality a native 
> compiler could have a different opinion, and this discrepancy could be 
> revealed e.g. when jextract generates a compound header which includes 
> 'foo.h' (we do that in the multi-header input case) - although I 
> understand that, right now, we use absolute paths in the includes of 
> the compound header, so maybe this discrepancy will not be noticeable.
>
> All this make me a bit uneasy w.r.t. to this change.
>
> Maurizio
>
>
>
> On 25/02/2019 15:12, Sundararajan Athijegannathan wrote:
>> Please review.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219653
>> Webrev: https://cr.openjdk.java.net/~sundar/8219653/webrev.00/
>>
>> Thanks,
>> -Sundar