jextract fails to compile generated source

[Ty Young]

Hi,


I attempted to use jextract to get the struct layout of 
"nvidia-xconfig.h" from:


https://github.com/NVIDIA/nvidia-xconfig


using:


jextract nvidia-xconfig.h


by accident(forgot you need --source at first) and it failed with:


https://pastebin.com/KgBpAAtd


Once I specified --source, the output I got wasn't expected either. The 
$constants file was a .class despite --source specified. I'm not seeing 
where the layouts are defined in the nvidia-xconfig_h.java file, so I'm 
assuming the layout information is stored there, unless I missed them.


This is the first time since I initially tried using the new jextract 
and I have to say I really don't like how it combined multiple native 
header bindings into a single file.


Looking at nvidia-xconfig_h.java I have no idea where half of the static 
methods are coming from. It's extremely confusing seeing dependency 
header static methods casually thrown into a single file and the end 
user using the bindings is going to be very confused when they refer to 
the native header file for information only to find nothing since it's 
the wrong one.


It also makes an otherwise already potentially long and hard to read 
binding generation even harder to read and understand, from a source 
code readability perspective. If I wanted to use a jextract source code 
binding as a guide on how I'd generate my own hand-made bindings I'd 
have to easily go through 2k lines of code.


The generation of a dozen helper classes is also a bit of an issue, IMO, 
but I've raised my issues before so I'm not going to go into those again.


A question though: is there any advantages to using MethodHandle's 
invokeExact vs. invoke? I randomly came across a StackOverflow(IIRC) 
post awhile ago where supposedly invokeExact is marginally faster but 
I'm not sure how true that is. I don't do benchmarking but if it's a 
noticeable speedup I'll change my code to use it.