[foreign] RFR 8212049: Improve jextract usability

[Sundararajan Athijegannathan]

I like --infer-rpath. Clean and tells exactly what it does.

-Sundar

On 11/10/18, 9:02 PM, Maurizio Cimadamore wrote:
>
>
> 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
>>>
>>>
>