[foreign] jextract issue with system headers

[Jorn Vernee]

Interesting. I think the defines are for use with #ifdef

Checking for duplicates seems like a good choice. I think discarding the 
macro constant, and keeping the one from the enum is fine in this case.

Jorn

Maurizio Cimadamore schreef op 2019-05-01 12:39:
> Hi,
> I was trying to rerun some examples I had with the new generation
> scheme. One of them has failed - it is a simple getpid test, that is,
> an extraction of the 'unistd.h' file:
> 
> $ jextract -t stdlib -d classes /usr/include/unistd.h
> java.lang.RuntimeException: In memory compilation failed:
> /stdlib/x86_64_linux_gnu/bits/confname_h.java:2451: error: method
> _PC_LINK_MAX() is already defined in interface confname_h
>     public int _PC_LINK_MAX();
>                ^
> /stdlib/x86_64_linux_gnu/bits/confname_h.java:2459: error: method
> _PC_MAX_CANON() is already defined in interface confname_h
>     public int _PC_MAX_CANON();
>                ^
> /stdlib/x86_64_linux_gnu/bits/confname_h.java:2467: error: method
> _PC_MAX_INPUT() is already defined in interface confname_h
>     public int _PC_MAX_INPUT();
> 
> The output goes on with 300 errors.
> 
> Turns out that jextract is generating duplicate constants, one coming
> from the  enum constant and one coming from a #define with same name -
> the pattern in the header is as follows:
> 
> /* Values for the NAME argument to `pathconf' and `fpathconf'. */
> enum
>   {
>     _PC_LINK_MAX,
> #define _PC_LINK_MAX                    _PC_LINK_MAX
>     _PC_MAX_CANON,
> #define _PC_MAX_CANON                   _PC_MAX_CANON
>     _PC_MAX_INPUT,
> ...
> }
> 
> 
> Should jextract check for duplicates before emitting a constant with
> same name? Or should we use some kind of mangling to distinguish
> between the #defined constants and the enum ones? I think I'd rather
> see the former in the short term.
> 
> Maurizio