Run jextract with libclang panama style

[Henry Jen]

> On Mar 20, 2018, at 3:51 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Looks good. I think I would drop the verify.sh shell, and the related makefile changes - you probably don't need them at this point, and running jtreg is 'easy enough’.
> 

OK.

> One thing that worries me with this kind of test is that there is a non trivial chance that the test will go out of sync if some changes are made to jextract (since we basically snapshotted the code base in a different folder). Let's go with it, but let's also keep an eye on how frequently does the test breaks, and ,maybe reassess at some time in the future.
> 

We need to keep both version of libjclang in sync anyway as long as we want to run jextract on top of this. Eventually, jextract may have a feature richer version running on panama stack because it’s easier than JNI.

> Small note: when comparing results, wouldn't it be more straightforward to do a byte-for-byte comparison on the jar outputs, rather than a file walk on a dir structure?
> 

I am not sure if the entries on jextract jar file will be in the same order, because the hash value were different when I started this test as a shell script, I can try again but unless I am certain how jar files are put together, this is more strict and precise.

Cheers,
Henry


> Cheers
> Maurizio
> 
> 
> On 15/03/18 07:31, Henry Jen wrote:
>> Please review the updated webrev[1], in which,
>> 
>> - Add TestJextractFFI.java as jtreg test. After considering different options, I decided to bite the bullet and simply use ProcessBuilder to run jextract and javac.
>> - Fix jdk.internal.clang source code to adapt recent refactoring of jdk.nicl API
>> 
>> I am debating whether we still want to have the Makefile and verify.sh, it’s convenient to run from command line sometimes without running jtreg and maybe more clear to developer as a sample on how to use jextract(perhaps simply use a shell script and get rid of Makefile). But not sure if that worth clogging codebase.
>> 
>> Thoughts?
>> 
>> Cheers,
>> Henry
>> 
>> [1] http://cr.openjdk.java.net/~henryjen/panama/clang-ffi/1/webrev/
>> 
>>> On Mar 5, 2018, at 12:10 AM, Henry Jen <henry.jen at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> This webrev[1] add a test case that
>>> 
>>> 1. Run jextract against libclang
>>> 2. Compile the module jdk.internal.clang implemented in libclang native API using panama stack instead of JNI
>>> 3. Run jextract itself on top of the libclang panama stack by patching jdk.internal.clang module
>>> 4. Compare result from step 1 and step 3 so that both should have same result
>>> 
>>> To run the test, run the verify.sh from within the test directory.
>>> 
>>> As for now, it’s sort of hacked together to demonstrate the process of using native library, in this case, libclang itself. By running jextract we get to test the binding is actually working. We will need to make it fit better with the testing framework.
>>> 
>>> Cheers,
>>> Henry
>>> 
>>> [1] http://cr.openjdk.java.net/~henryjen/panama/clang-ffi/0/webrev/
>