jextract fails to compile generated source

[Maurizio Cimadamore]

On 28/06/2020 21:11, Ty Young wrote:
> 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.

In all the examples I tried I have almost the opposite feedback. In the 
old world I had to *chase* function and structs down to paths which 
were, ultimately, system-dependent. When you write code in C, you do not 
get a qualified view of the world - all functions and structs and 
globals are thrown into the same namespace. If you want to inject more 
structure, well, fine, but note that this structure is not there to 
begin with, and a C programmer just _uses_ all the symbols that are 
imported, either directly or indirectly.

I also don't get how, in the current approach you can " refer to the 
native header file for information only to find nothing since it's the 
wrong one" - this was happening before 100% of times; now I just seem to 
be able to copy and past idiomatic C code into my Java project, make few 
adjustments and 90% of the times things just work.

>
>
> 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.

I'm having a lot of trouble sympathizing with comments such as these. 
The goal of jextract is not to generate beautiful generated code (heck, 
it's generated code). The goal is to let you target the library you want 
to target as easily as possible (given the interop support provided in 
terms of MH and VH is efficient, but can be perceived as sharp). And I 
think, by looking at all the samples we tried to port, plus other 
examples not listed in the public documents, that it does a pretty good 
job at that.

If you really want to understand what jextract does when generating 
bindings, there's no need to write 2k lines of code - just write a 
simple header, with one function, one struct (or look at some of the 
existing jextract tests) - these will generate much simpler output, 
which could be more amenable to reading. Jumping in the middle of 2k 
lines of code to learn something isn't fun, I agree, but I don' get why 
it's jextract fault if the library you are trying to extract ends up 
with that many symbols - it would be like complaining with the IDE 
because it generated a 2K LoC class for a very complex UI created with 
an interactive UI designer... that's why you use tooling.

P.S.

I think one of the problems here (at least in the past) is that most of 
the feedback refer to the NVML library which, unfortunately, it's just 
not the best library to get started with jextract (given that, IIRC, it 
doesn't even export a list of symbols that it provides, but has you 
finding such symbols dynamically, through specific lookup functions). So 
I think that, in some way at least, you can't just fire jextract use the 
bindings and forget about all the stuff that's inside - because some of 
the stuff you need just isn't there.

Maurizio