error: too many constants jextract Windows.h

[Michael Ennen]

Okay. Understood.

For now I will just manually copy in what is needed for my experiments.

Windows.h is kind of a mess in terms of one not being able to include only
parts of it, but just a huge monolith.

On Fri, Sep 25, 2020 at 3:21 AM Jorn Vernee <jorn.vernee at oracle.com> wrote:

> Hi,
>
> Windows.h as a whole is too big, so you need to use the --filter option
> to filter out the headers you need. For some headers I've found that the
> documentation wants you to include Windows.h, otherwise the parsing will
> not work, and this is the case with jextract as well. But, it should
> also mention which header contains the actual declaration, so you can
> use that one for the filter. (e.g. --filter "header.h").
>
> Figuring out a way to extract Windows.h without needing a filter is
> still an open problem.
>
> HTH,
> Jorn
>
> On 24/09/2020 20:35, Maurizio Cimadamore wrote:
> > I see that... there are really a tons of functions/constants dropped
> > in windows_h.
> >
> > I recall Jorn having done this at some point, maybe he can provide
> > some guidance of what set of filters to add to the command line to end
> > up with a reasonable subset?
> >
> > Maurizio
> >
> > On 24/09/2020 19:04, Maurizio Cimadamore wrote:
> >> We already have logic in place to split the underlying constants
> >> (e.g. method handles/var handles/layouts) - but this is for the
> >> various constant files (here it seems like the error is coming from
> >> the main windows_h file).
> >>
> >> I'll try to see if I can reproduce - it's mildly surprising to see
> >> _that many_ constants ending up in the constant pool here.
> >>
> >> Maurizio
> >>
> >> On 24/09/2020 05:44, Michael Ennen wrote:
> >>> Now that the character escaping has been fixed I can get a little bit
> >>> further trying to compile
> >>> the jextract result of Windows.h.
> >>>
> >>> This time, however, I am running into a Java language limitation:
> >>>
> >>> src\main\java\com\dx12\Windows_h.java:10: error: too many constants
> >>>
> >>> I am not sure if there is a nice way around this...I remember
> >>> reading that
> >>> the Android library did something to overcome this "limitation" but
> >>> that
> >>> was years ago.
> >>>
>


-- 
Michael Ennen