[foreign] RFR 8212049: Improve jextract usability

Sundararajan Athijegannathan sundararajan.athijegannathan at oracle.com
Thu Oct 11 15:37:14 UTC 2018


All tests pass on Mac. Questions:

* Do we need some escaped name for "auto"? something that can't occur in 
file system normally?

Is the debug print leftover or help for debugging test? (JtregJextract 
driver)

+        System.err.println(jextrOpts);


-Sundar


On 11/10/18, 8:32 PM, Maurizio Cimadamore wrote:
> Hi,
> quoting from the JBS issue:
>
> "There are some low hanging fruits that could significantly improve 
> usability of jextract:
>
> 1) auto excluding symbols not found with -l/-L
> 2) inferring rpath from -L/-l (e.g. -rpath:auto)
> 3) applying same header settings (e.g. rpath) to ALL headers being 
> extracted, not just the explicitly provided ones
> 4) treat headers in the same folders as a 'unit' (even if in system 
> folders), and ignore dependencies outside this unit
>
> (3) and (4) are particularly important because right now we tend to 
> have many subtle asymmetries between different header files being 
> generated, depending on whether they are explicit/implicit and whether 
> they live in system folders or not. This makes the jextract behaviour 
> particularly hard to grasp."
>
> This patch fixes all 1-4 (and additionally fixes a crash when 
> libraries could not be loaded by the symbol checker enabled with -l 
> and -L).
>
> I've added (with help of Sundar many thanks!) tests for (1), (2), and 
> (3) (and the crash issue). I also have test for (4), although is 
> probably a bit limited (but better than nothing): I simply check that 
> when extracting an header that depends on <stdio.h> we don't end up 
> generating artifacts for stdio too.
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8212049_v3/webrev/
>
> You might want to check any existing local tests you might have to 
> make sure nothing is broken by these cha
>
> Maurizio
>
>


More information about the panama-dev mailing list