[foreign] jextract, distilled

[Maurizio Cimadamore]

<snip>

> They are, however I think both A and B can be fixed(or smoothed over) 
> by this new API if it provided a standardized(in the literal sense) 
> Java interface(s) for defining a jextract binding generation.
>
>
> For example:
>
>
> // returns a list of libraries required by this binding extraction
>
> public List<File> getLibraries();
>
>
> and
>
>
> // returns a list of header files required by this binding extraction
>
> public List<File> getHeaders();
>
>
> etc.
>
>
> The idea here is to define a standardized, repeatable way of 
> generating bindings for higher level devs's targeted platform and add 
> a way to submit them to jextract via its API. Currently it seems like 
> everything is done via String instead of something more robust.
Ah sure. The API included in the document is (as stated in the document) 
just a sketch; of course I imagine a bunch of iterations on the API so 
that we make sure that we expose the right set of abstractions; I think 
that, for example, a builder-like interface to set up the various 
options could work well (instead of passing a string array, as in the 
current sketch). But these are, in a sense, details (although I agree we 
should get them right).
>
>
> It might not be possible to generate "universal" bindings that Just 
> Work(TM) on every platform, but defining a standardized interface 
> implementations to specify various jextract commands *for* particular 
> platforms is. Once these are defined they aren't likely to change 
> often if ever.
>
>
> Of course, it's possible for this to be done yourself. I just think 
> it'd be nice if this was included by default as per the API.
>
>
>> As for C, we have discussed internally to maybe sprinkle some 
>> metadata on the bindings as a way to keep a 'link' to the place where 
>> they came from (which is also why the API has this Position 
>> abstraction - reifying that into, say, a java annotation is doable).
>
>
> The type of validation I was thinking of(relates to the above 
> standardized interface API somewhat) would required everything used to 
> generate the bindings be part of the meta data. Basically I'm  
> thinking of comparing the provided binding generation vs. a list of 
> valid, good generations and if it fails then an exception is thrown.

I see what you mean - e.g. you want to capture the info "this set of 
bindings was generated using XYZ", so that, if on a subsequent 
extraction you start to see some divergence, you can halt. It's 
definitively something that can be explored. That said, using the API is 
really easy to just dump whatever is parsed - in fact, I wrote a 
declaration dumper which is part of the minimal jextract I've built on 
top of the API, whose output is probably very similar to the info you 
are looking for.

I'd say that, at the moment, we should focus on making the API flexible 
so that we can build these kind of things (e.g. recipe dumper, 
validation) on top. Whether these tools will be provided by default or 
not, that's a secondary question.

>
>
> Comparing the library vs. the bindings kinda slipped my mind since the 
> native API I'm working with is both backwards compatible and 
> cross-platform compatible(except the library name itself, go figure), 
> but yeah that's be really nice to have too.
>
>
> Would a properties file inside the bindings jar not work better and 
> easier than annotations?

If you want to dump the guts of the extraction process, yes. I thought 
you were only looking for a back-link between binding and original 
header file position, in which case an annotation is ok.

Maurizio

>
>
>>
>> Maurizio
>>
>>>
>>>
>>> Could this maybe be added?
>>>
>>>
>>>
>>> On 11/22/19 10:14 AM, Maurizio Cimadamore wrote:
>>>> Hi,
>>>> as we got foreign memory access and foreign function access on a 
>>>> much more solid footing --- using VarHandle and MethodHandle, 
>>>> respectively --- I thought it was time to look again at jextract 
>>>> and see how we could make these new primitives play a more central 
>>>> part in the extraction process. The writeup below captures my 
>>>> thinking on this topic:
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/panama/jextract_distilled.html
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>>