[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