[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