<div dir="ltr">It's probably possible to do, but looks roundabout.<div><br></div><div>Here is my setup in more detail:</div><div>1. A header is given to the application. It calls 'parse' on it to get all the Declarations.</div><div>2. The user can configure which declarations to include in the GUI, and also the other options such as class name, macros, output dir etc.</div><div>3. The 'run' method is called with the arguments generated from the configuration.</div><div><br></div><div>It's all in-memory.</div><div><br></div><div>With --dump-includes:</div><div>1. A header is given to the application. A JSON file is created.</div><div>2. The file is read and parsed to produce the Declarations. Configuring a JSON parser is already a lot of work for polymorphic sybtyping (all the types of Declarations). Will jextract provide a parser? What is the format? Is it stable?</div><div>3. Is 2 above.</div><div>4. Is 3 above.</div><div><br></div><div>So we complicated things by creating a file from which we need to read the data that would otherwise be given to us directly by 'parse'. At least this is my understanding.</div><div><br></div><div>Speaking of 'parse', I notice that it doesn't throw an exception on a missing '#include <header.h>' as it used to. Now I only see a printed error. Has this changed? Is there a way to capture this error somehow so that the user knows something went wrong?</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jan 28, 2025 at 5:06 PM Jorn Vernee <<a href="mailto:jorn.vernee@oracle.com">jorn.vernee@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    <p>> There is no need for a dump.<br>
      <br>
      But, do you think you could do the things you're doing, using
      JextractTool::parse, by using --dump-includes instead?</p>
    <p>I'm trying to assess if we even need the API at all, or if we can
      just have the ToolProvider.<br>
    </p>
    <p>Jorn<br>
    </p>
    <div>On 28-1-2025 15:12, Nir Lisker wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">I use
        <div>JextractTool.parse(List<String> arg0, String... arg1)</div>
        <div>to inspect given header files. Then I use</div>
        ToolProvider.run(PrintStream out, PrintStream err, String...
        args)
        <div>which is not Jextract-specific to run the tool with the
          user's configuration. There is no need for a dump.</div>
        <div><br>
        </div>
        <div>I want to release an alpha soon so you'll be able to see
          how it works.</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Tue, Jan 28, 2025 at
          2:28 PM Jorn Vernee <<a href="mailto:jorn.vernee@oracle.com" target="_blank">jorn.vernee@oracle.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey
          Nir,<br>
          <br>
          The jextract API has been neglected for a while (as you've
          found). <br>
          Initially it was a way of avoiding adding many flags to
          jextract, to do <br>
          things like filtering, renaming, and other things. The idea
          being that <br>
          if users wanted more control of what jextract did, they could
          use the <br>
          API. But, now it seems like we're moving in that direction any
          way, with <br>
          the JSON based configuration: <br>
          <a href="https://bugs.openjdk.org/browse/CODETOOLS-7903788" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/CODETOOLS-7903788</a><br>
          <br>
          I think we need to re-asses which use cases the jextract API
          addresses, <br>
          and whether using jextract through the ToolProvider interface,
          with the <br>
          extended configuration options, is also an option.<br>
          <br>
          IIRC your use case is filtering the jextract output, right? Do
          you think <br>
          it would be possible to use the ToolProvider interface with a
          <br>
          combination of --dump-includes, and automatically generated <br>
          --include-XXX flags, to achieve the same level of
          functionality?<br>
          <br>
          Jorn<br>
          <br>
          On 26-1-2025 08:51, Nir Lisker wrote:<br>
          > Hi,<br>
          ><br>
          > There are several public methods the
          JextractTool exposes. Please <br>
          > javadoc to these methods so tool users will know what
          they do and how <br>
          > to use them.<br>
          ><br>
          > Thanks,<br>
          > - Nir<br>
        </blockquote>
      </div>
    </blockquote>
  </div>

</blockquote></div>