jextract fails to compile generated source

[Maurizio Cimadamore]

On 28/06/2020 21:11, Ty Young wrote:
> y 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.
>
I tried to extract the same, to see what's happening.

The first problem you ran into is caused by the fact that the header 
file has an hyphen char - which has been fixed by Sundar (I just worked 
around by renaming the header).

After jextract finished, I noticed that the generated bindings contained 
lots of reference to standard library which you probably don't want - so 
I added this option:

--filter nvidia-xconfig

(assuming you cloned the repo in a folder with that name).

After that, the bindings only contained nvidia stuff.

I noticed one annoying thing, which was that jextract is adding a C 
prefix to all typedef names, not sure that's what we want and I'm sure 
that will be rectified.

Other than that, bindings seemed ok - although I couldn't really find a 
way to tell - this seems to be mostly a binary tool - all the functions 
in the main header take an Options* - but such an array is only 
generated in a parse function that is declared as static, and hence not 
available for external use.

I can't help but feeling that, again, this is not just an "extract a 
library and use it" example - but something where you'd have to hack in 
order to use the few exported functions in the _same_ way the binary 
tool is using them, which probably consists in recreating a lot of the 
stuff that is done by the native code... am I correct? (I couldn't find 
any example online of existing clients using this, so it's kind of hard 
for me to verify how jextract bindings fare compared with "idiomatic" 
use of this library).

Maurizio