[foreign] RFR 8212049: Improve jextract usability

[Maurizio Cimadamore]

New webrev

http://cr.openjdk.java.net/~mcimadamore/panama/8212049_v4/

Replaces '-rpath auto' with '-infer-rpath'

Maurizio


On 11/10/18 16:59, Sundararajan Athijegannathan wrote:
> 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
>>>>
>>>>
>>