jextract woes

[Michael Zucchi]

Ok, using the platform clang headers - by default - I get 8000 lines of 
this:

WARNING: Using incubator modules: jdk.incubator.foreign, 
jdk.incubator.jextract
java.lang.UnsupportedOperationException
         at 
jdk.incubator.jextract/jdk.incubator.jextract.tool.TypeTranslator.visitArray(TypeTranslator.java:98)
         at 
jdk.incubator.jextract/jdk.incubator.jextract.tool.TypeTranslator.visitArray(TypeTranslator.java:35)
         at 
jdk.incubator.jextract/jdk.internal.jextract.impl.TypeImpl$ArrayImpl.accept(TypeImpl.java:231)


But using --filter=cl.h I get something similar to my current generator, 
only it's much much slower to create.

But it looks interesting and will try using it - although i'm confused 
now about which panama branch should I be working against?  Or should i 
just run the tool from one and use it with the foreign-abi?

Some quick observations before I try to go outside:

  * One would usually want to export defines and enums to the library
    user (CL_* ints for opencl) but almost definitely not the low-level
    calls and definitely not the variable accessors.  Having them in
    separate files would make this much easier.
  * +1 for outputting source rather than a jar.
  * I know it's probably necessary for namespace reasons but those
    struct accessor names are nasty.  Some libraries are going to want
    to auto-generate concrete classes some other way  so it wont matter
    (vulkan definitely), others perhaps not (ffmpeg).
  * specifically with cl.h, _cl_image_desc has generated no way to
    access the unnamed union fields "buffer" and "mem_object". In C
    these would just appear as "cl_image_desc.buffer" and
    "cl_image_desc.mem_object" (i.e. unqualified) with the same struct
    offset.
  * Should all the calls catch Throwable and then assert?  e.g.
    something that calls c that calls java, can the java throw an
    exception to be passed back up as one could with jni?  This isn't
    really something that can be automated though.

Some simple ideas which I don't think are out of scope (when the time 
comes to consider them):

  * option to disable get/setter generation and if so, optionally
    varhandles (for libraries where many fields exist that aren't public).
  * option to put enum/#defines in another class
  * option to provide files with specific list of functions / structs /
    enum / defines to generate and not just a regex.

I guess It has the same problem I have with my generator - which is both 
a benefit and a curse - there's just no type checking beyond primitive 
types.  When you write jni you have all the facilities of the C language 
and the Java language at your disposal.  Here you have ... "every 
pointer is a 'void *'".  It works in practice but it is definitely 
error-prone.  I don't have anything to suggest though because either you 
have to put a big layer of common abstraction over everything which is 
both a cost and a constraint (and gets cumbersome real fast), or you 
make something tighter but application-specific outside of jextract.

Finally, this fails to compile presumably due to the bitfields (just 
something i used to test a generator):

struct data {
         struct data *next;

         int a;
         int b;
         int c:3;
         unsigned d:5;
         int (*test_a)(int a, int b);

         struct data **list;
};

void print_data(struct data *data);

void *api_func(const char *name);

I hate bitfields, but they get used even in public apis (or at least, 
their header files).


On 27/1/20 10:43 am, Maurizio Cimadamore wrote:
> I noticed that problem too - I was trying to use jextract on opencl 
> headers too to take a look at what came out and found that issue.
>
> This is something we fixed in the old jextract by having it include 
> some clang headers by default - Sundar, I think this change is missing 
> from current foreign-jextract?
>
> For now you can workaround like this (at least, this is what I used):
>
> jextract --filter cl.h -I 
> /opt/clang/clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04/lib/clang/9.0.0/include/ 
> /usr/include/CL/cl.h
>
> This gave me something that was enough to Panama-ize some basic OpenCL 
> examples I found on the web.
>
> (The clang path you see is the one you use to build the Panama JDK)
>
> Maurizio