<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Florian, it seems you missed a comment on that topic I wrote a
      while ago.</p>
    <p>There is also the need to have a tuple that matches
      controllertype to controllerunit to get rid of a big peace of
      duplicated code from cpuinfo.pas in lazarus.</p>
    <p>Lazarus needs to know which unit to include so that codetools can
      do their magic. In current implementation parts of controllertypes
      are duplicated in lazarus code.</p>
    <p><br>
    </p>
    <p>To get rid of this lazarus will not only need to know the
      available controllertypes, it will also need to have the mapping
      from controllertype tu unitname like this:<br>
    </p>
    <controllertype name="NUCLEOF103RB" unit="STM32F103RB" /><b><br>
    </b>
    <p>in the xml.</p>
    <p>Example:<br>
    </p>
    <p>~/fpcupdeluxe-test/fpc/bin/aarch64-darwin/fpc -Tembedded -Parm
      -ix</p>
    <p><?xml version="1.0" encoding="utf-8"?><br>
      <fpcoutput><br>
        <info><br>
          <ostargets><br>
      ...</p>
    <p>    </ostargets><br>
          <cpuinstructionsets><br>
      ...</p>
    <p>    </cpuinstructionsets><br>
          <fpuinstructionsets><br>
      ...</p>
    <p>    </fpuinstructionsets><br>
          <abis><br>
      ...</p>
    <p>    </abis><br>
      ...</p>
    <p>    <optimizations><br>
    </p>
    <p>    </optimizations><br>
          <wpoptimizations><br>
      ...</p>
    <p>    </wpoptimizations><br>
          <modeswitches><br>
      ...</p>
    <p>    </modeswitches><br>
          <asmmodes><br>
      ...</p>
    <p>    </asmmodes><br>
          <controllertypes></p>
    <p><b>...</b></p>
    <p><b>      <controllertype name="NUCLEOF103RB"
        unit="STM32F103RB" /></b><b><br>
      </b>...<br>
    </p>
    <p>    </controllertypes><br>
          <features><br>
      ...</p>
    <p>    </features><br>
          <codegeneratorbackend>FPC</codegeneratorbackend><br>
        </info><br>
      </fpcoutput><br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Am 02.04.21 um 15:07 schrieb Michael
      Van Canneyt via fpc-devel:<br>
    </div>
    <blockquote type="cite"
      cite="mid:alpine.DEB.2.22.394.2104021507080.619782@home">
      <br>
      <br>
      On Fri, 2 Apr 2021, Florian Klämpfl via fpc-devel wrote:
      <br>
      <br>
      <blockquote type="cite">
        <br>
        <br>
        <blockquote type="cite">Am 07.03.2021 um 15:12 schrieb Florian
          Klämpfl via fpc-devel <a class="moz-txt-link-rfc2396E" href="mailto:fpc-devel@lists.freepascal.org"><fpc-devel@lists.freepascal.org></a>:
          <br>
          <br>
          Am 07.03.21 um 12:05 schrieb Alfred via fpc-devel:
          <br>
          <blockquote type="cite">Hello,
            <br>
            As a follow-up on a Lazarus feature request.
            <br>
            Among other applications, Lazarus uses some hard-coded list
            that represent FPC features. Like supported MCU and boards.
            It would be (much) more convenient to parse the FPC output
            itself to supply this info. And that could be made easy by
            using XML as FPC output.
            <br>
            Besides the above, I would welcome more features to be
            available through FPC itself.
            <br>
            FPC uses system files, located in "compiler/systems". With
            all kinds of settings. Like alignment and calling convention
            and linker to use.
            <br>
            FPC uses search-paths. Some user defined through fpc.cfg,
            some build-in. See all -F... compiler settings.
            <br>
            It would be nice to be able to get info through FPC itself
            about these settings and paths.
            <br>
            As maintainer of fpcupdeluxe, often I need to parse fpc.cfg
            by hand. Or look into a file like fpmkunit.pp to find the
            valid FPC targets. Or parse the Makefile to find all
            available subarchs when building a cross-compiler.
            <br>
            For a start, I would favor a XML/JSON output of fpc -i.
            Would be very nice to use its output.
            <br>
          </blockquote>
          <br>
          I added a first experimental implementation in r48897. It does
          not cover full -i, so far only to show how it could look like.
          Any comments?
          <br>
        </blockquote>
        <br>
        Meanwhile I completed it.
        <br>
        <br>
        So if somebody thinks it’s useful, the json output can be added
        as well.
        <br>
      </blockquote>
      <br>
      Will do, thanks!
      <br>
      <br>
      Michael.<br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
fpc-devel maillist  -  <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>
</pre>
    </blockquote>
  </body>
</html>