<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 23, 2020, at 12:36, Dominik Montada <<a href="mailto:dominik.montada@hightec-rt.com" class="">dominik.montada@hightec-rt.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
  
  <div class=""><p class=""><br class="">
    </p>
    <div class="moz-cite-prefix">Am 23.10.20 um 16:30 schrieb Louis
      Dionne:<br class="">
    </div>
    <blockquote type="cite" cite="mid:2152E8A0-4E34-42F1-BFDF-78878F48A447@apple.com" class="">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
      <br class="">
      <div class=""><br class="">
        <blockquote type="cite" class="">
          <div class="">On Oct 23, 2020, at 02:25, Dominik Montada <<a href="mailto:dominik.montada@hightec-rt.com" class="" moz-do-not-send="true">dominik.montada@hightec-rt.com</a>>
            wrote:</div>
          <br class="Apple-interchange-newline">
          <div class=""><span style="caret-color: rgb(0, 0, 0);
              font-family: Helvetica; font-size: 12px; font-style:
              normal; font-variant-caps: normal; font-weight: normal;
              letter-spacing: normal; text-align: start; text-indent:
              0px; text-transform: none; white-space: normal;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;
              text-decoration: none; float: none; display: inline
              !important;" class="">Hi Louis,</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica;
              font-size: 12px; font-style: normal; font-variant-caps:
              normal; font-weight: normal; letter-spacing: normal;
              text-align: start; text-indent: 0px; text-transform: none;
              white-space: normal; word-spacing: 0px;
              -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
            <br style="caret-color: rgb(0, 0, 0); font-family:
              Helvetica; font-size: 12px; font-style: normal;
              font-variant-caps: normal; font-weight: normal;
              letter-spacing: normal; text-align: start; text-indent:
              0px; text-transform: none; white-space: normal;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;
              text-decoration: none;" class="">
            <span style="caret-color: rgb(0, 0, 0); font-family:
              Helvetica; font-size: 12px; font-style: normal;
              font-variant-caps: normal; font-weight: normal;
              letter-spacing: normal; text-align: start; text-indent:
              0px; text-transform: none; white-space: normal;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;
              text-decoration: none; float: none; display: inline
              !important;" class="">big +1 from me. I recently set up
              the runtimes for our downstream toolchain and to be honest
              it was quite a pain to get everything working. Due to the
              complexity we ended up creating our own CMake cache to
              make the configuration easier. We also tried to use the
              existing toolchain build. But since it tries to build the
              runtimes immediately after it built the compiler we cannot
              use it, as we have to build our C library first. So having
              a "unified standalone" approach sounds just like something
              that would make this use-case a lot easier.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica;
              font-size: 12px; font-style: normal; font-variant-caps:
              normal; font-weight: normal; letter-spacing: normal;
              text-align: start; text-indent: 0px; text-transform: none;
              white-space: normal; word-spacing: 0px;
              -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
          </div>
        </blockquote>
        <div class=""><br class="">
        </div>
        Glad to see support!</div>
      <div class=""><br class="">
        <blockquote type="cite" class="">
          <div class=""><br style="caret-color: rgb(0, 0, 0);
              font-family: Helvetica; font-size: 12px; font-style:
              normal; font-variant-caps: normal; font-weight: normal;
              letter-spacing: normal; text-align: start; text-indent:
              0px; text-transform: none; white-space: normal;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;
              text-decoration: none;" class="">
            <span style="caret-color: rgb(0, 0, 0); font-family:
              Helvetica; font-size: 12px; font-style: normal;
              font-variant-caps: normal; font-weight: normal;
              letter-spacing: normal; text-align: start; text-indent:
              0px; text-transform: none; white-space: normal;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;
              text-decoration: none; float: none; display: inline
              !important;" class="">Do you already have an idea of how a
              multilib build would look like with your proposed setup? </span></div>
        </blockquote>
        <div class=""><br class="">
        </div>
        <div class="">Can you define what you mean by a multilib build? Do you
          mean building for several architectures at once? Do you
          produce the libs for each architecture in different
          directories?</div>
      </div>
    </blockquote><p class="">Yes, but also more than that: our target has different
      architectures, so we build each library for each architecture. But
      on top of that, we also build the libraries with different
      configurations, e.g. with or without exceptions. The Fuchsia
      toolchain is doing something similar IIRC. We produce these
      libraries in different directories per architecture and per
      configuration, so for example:</p><p class="">target/arch1/except<br class="">
      target/arch1/noexcept<br class="">
      target/arch2/except<br class="">
      target/arch2/noexcept<br class="">
    </p>
    <blockquote type="cite" cite="mid:2152E8A0-4E34-42F1-BFDF-78878F48A447@apple.com" class="">
      <div class="">
        <div class=""><br class="">
        </div>
        <div class="">If you're talking about what I'm thinking of, I believe the
          simplest and most CMake-friendly way of doing it would be to
          have multiple CMake invocations. We can hide those behind a
          "driver" build like what the Runtimes build does, for example,
          but the libc++/libc++abi/libunwind builds themselves wouldn't
          be aware they're being built for multiple archs.</div>
      </div>
    </blockquote>
    With the use-case described above, we simply do one CMake invocation
    for each library configuration.<br class=""></div></div></blockquote><div><br class=""></div><div>Yes, I think one CMake invocation per configuration is the way to go. Unlike other build systems, it seems like CMake wasn't really designed with multi-configuration builds in mind.</div><div><br class=""></div><div>Now, one can wrap these multiple CMake invocations in a single one by using a "driving" CMakeLists.txt and calls to ExternalProject_add if so desired, but it's really another layer on top.</div></div><br class=""></body></html>