[foreign] RFR 8208199: Revisit one interface per header file approach
Sundararajan Athijegannathan
sundararajan.athijegannathan at oracle.com
Wed Aug 8 12:25:17 UTC 2018
I thought about this a bit more. We have NativeHeader annotation that
mentions a header path + declarations (it is called "NativeHeader" and
not "NativeHeaders"). If we combine declarations from multiple header
files, this annotation won't be accurate. Yes, NativeLocation does
mention file - but that annotation is considered optional and it is
considered as "debug info".
Also there is an outside chance of reaching per .class limitations when
processing a deeply nested header file (if we fold all declarations in
one interface). May I suggest that we go with the current scheme (which
is minimal changes) and revisit based on use-cases?
Updated webrev:
http://cr.openjdk.java.net/~sundar/8208199/webrev.01/index.html
Change: Folded ConstantArray, IncompleteArray cases in HeaderFile.java
Thanks,
-Sundar
On 03/08/18, 9:56 PM, Maurizio Cimadamore wrote:
> I agree we need something to treat 'related' header files in a more
> cohesive fashion.
>
> I've also recently stumbled onto a similar issue with the clang
> Index.h header, which is importing few associated header such as
> CXString.h - defining types which virtually ought to belong to the
> same namespace.
>
> That said, I'm not sure using inheritance is the best way to provide
> such coupling. An alternative would be, for instance, to simply
> recursively add external header definitions into the main header (the
> one importing them). For some reason, something like this would seem
> more in spirit with C - where importing an header really amounts at
> adding the imported definitions on the importee.
>
> I also think that we should provide some mechanism to control this
> merging behavior; privately I've suggested an option 'follow-includes'
> which takes a path (or a list of paths), and which allows to follow
> headers onto specific folders. An option like this would be useful to
> deal with what Henry set out to do yesterday - e.g. allow jextract to
> recursively process headers in system libraries.
>
> So, in conclusion, I'm not opposed with the effort, but I'm not sure
> we have found the right stacking yet.
>
> Maurizio
>
>
> On 03/08/18 15:07, Sundararajan Athijegannathan wrote:
>> Please review.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8208199
>> Webrev: http://cr.openjdk.java.net/~sundar/8208199/webrev.00/index.html
>>
>> Thanks,
>> -Sundar
>
More information about the panama-dev
mailing list