[foreign] RFC: Additional jextract filtering

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Mon Mar 11 15:29:57 UTC 2019


Btw, as for macros and enums, I'm afraid the current logic is not 
minimal enough; for instance, it is very likely that almost all headers 
would pull in constants from common headers such as stdint.h - do we 
really want those to show up? Most of the times those constants are 
relevant for the implementation of the library, much much less for the 
library client.

I'd propose that for enums and macros we'd adopt a path-based filtering, 
so that we do not add macro symbols and/or enums for headers that are in 
a different folder from the one that is the target of jextract.

(of course there should be a way to disable this adaptive filtering - 
which is probably needed for system libs - but my guess is that in 99% 
of cases it will just works for 3rd party libs such as python, 
tensorflow, sqlite & co).

Maurizio

On 11/03/2019 15:12, Maurizio Cimadamore wrote:
>
> On 11/03/2019 13:45, Jorn Vernee wrote:
>> I can separate the parts of the patch a little bit into; Filter 
>> refactor + root set compute, and then leave the option changes out of 
>> it. But those 2 alone do not affect the filtering, since the root set 
>> is only used when filtering non-symbol/macro elements. 
>
> I guess then what I'm suggesting is to automatically filter out 
> elements not in the root set, and see how that works out.
>
> Maurizio
>
>


More information about the panama-dev mailing list