[foreign] RFR 8212049: Improve jextract usability

[Maurizio Cimadamore]

Does the --infer-rpath option address your conern?

Maurizio


On 11/10/18 16:35, Henry Jen wrote:
> 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
>>>
>>>