[foreign] RFR 8212049: Improve jextract usability

[Henry Jen]

It’s good, with a nitpick. I prefer to have separate option to infer rpath instead of —rpath=auto. It’s just a matter not to impost unnecessary limitation. Who knows if user like to have a folder named auto.

Cheers,
Henry


> On Oct 11, 2018, at 8:37 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> 
> 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
>> 
>>