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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Mon Feb 25 15:49:37 UTC 2019


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


More information about the panama-dev mailing list