[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