Building CUDA bindings for Windows with jextract

[Maurizio Cimadamore]

<snip>
>
>
>> The main issue here is what we have been calling 'library-centric' 
>> approach - that is, instead of generating many separate classes - 
>> generate a single root class which has all the required member 
>> functions (the ones that appear in the shared library), and have all 
>> required dependencies added in as inner classes. That would indicate 
>> more clearly where you have to  look for.
>>
>> Note also that, for the purpose of looking inside classes (w/o using 
>> a jar) you can also use jextract with "-d <dirname>" and output 
>> classes into a folder, uncompressed.
>
> Even if there are class files: Some of the CUDA-based libraries 
> contain >4000 functions, some of them taking 30 parameters. Generating 
> even "empty" JavaDocs just to be able to easily browse through the API 
> could be helpful. (Not an issue of jextract either, though. Using a 
> decompiler was fine for me.)
  Point taken - it would be nice to see the comments in the C API added 
to the relevant Java API elements generated by jextract (in some way to 
be determined).
>
>
>> The long term solution would be the ability to reuse jextract runs by 
>> pointing jextract at a previous extracted library.
>>
>> That said, I believe you should be able to extract all three 
>> libraries in a single shot, by giving the three headers as input to 
>> jextract (and the three libraries...); that will generate only one 
>> version of everything. I used this approach for OpenGL which also 
>> relies on a number of dependent headers - and generated a single jar.
>
> For the first, basic tests, one could pack all libraries into one. But 
> in terms of modularity (and proper package names), having the option 
> to declare already generated dependencies would be favorable. I also 
> think about the case where new libraries are published later. (This 
> was the case for CUDA, but certainly for other libraries as well).
> I don't have the slightest idea of how jextract works internally 
> (although I went through some related issues, probably: Some of the 
> JCuda code is auto-generated, and I'm using the Eclipse CDT to 
> internally parse the header files into an AST, from which some of the 
> JNI-bindings are generated). But I could imagine that is is tricky to 
> figure out the required "mapping" between existing headers/JARs, and 
> the headers that are included by others. In fact, this can become 
> arbitrarily complicated (or even impossible) when the preprocessor 
> comes into play...

There are two competing forces here - on the one hand, you would like to 
reuse types s much as possible. On the other hand you would like to 
avoid accidental side-effects between different libraries. If a library 
A uses two libraries B and C, in principle you'd like to add B.jar and 
C.jar onto the classpath and be done with it. If B and C have been 
generated by different maintainers, even if both happen to have a common 
type T, there's no guarantee that B.T and C.T will be bitwise 
identical/compatible because the different providers might have needed 
to tweak some preprocessor flag to get the extraction just right in the 
B vs. the C case.

So, after some discussion, we kind of concluded that sharing stuff 
between runs is, most of the times, a siren song that goes against ease 
of redistribution.

That can be mitigated with APIs (e.g. to convert types that are 
'supposedly the same' - as in your example below), or with tools, to 
take a couple of jar files and merge them together by dropping the 
shared artifacts.

>
>
>> Again, I believe this situation will be much improved when we'll move 
>> from an header-centric view (which of course expose all levels of 
>> brittleness) towards a more library-centric view of the extraction 
>> process.
>
> I'm not entirely sure whether I understood this correctly. It sounds 
> like the move to the "library-centric" approach was on the agenda...?
> And wouldn't that mean that for headers like
>     exampleDataType.h
>     libA.h (including exampleDataType.h)
>     libB.h (also including exampleDataType.h)
> the class structure would be roughly like this:
>     class LibA {
>         private static class ExampleDataType {}
>     }
>     class LibB {
>         private static class ExampleDataType {}
>     }
> making both "ExampleDataType" bindings be different types, and thus 
> incompatible?
>
> (BTW: If any of my dumb questions has already been discussed, you can 
> ignore them (or maybe point me to the respective thread))

See above.


Cheers
Maurizio