[foreign] RFR 8212049: Improve jextract usability

[Maurizio Cimadamore]

On 11/10/18 16:37, Sundararajan Athijegannathan wrote:
>
> All tests pass on Mac. Questions:
>
> * Do we need some escaped name for "auto"? something that can't occur 
> in file system normally?
What about using a new flag - e.g.

rpath:auto

This is a new option, but shares same radix.

Or we could have something completely different:

--infer-rpath

Suggestions?
>
> Is the debug print leftover or help for debugging test? (JtregJextract 
> driver)
>
> +        System.err.println(jextrOpts);
Whoops

Maurizio
>
>
> -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
>>
>>