<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 8/24/2016 1:20 PM, Rafael Espíndola wrote:<br>
    <blockquote
cite="mid:CAG3jReJbLu_isB0A8cP+P_bCuSzMJPcYNm=0uGQvLEv7mKrZeA@mail.gmail.com"
      type="cite">
      <p dir="ltr">We need a demangler in llvm, and that requires
        annoying tradeoffs:</p>
      <p dir="ltr">* llvm depends on libc++abi.<br>
        * libc++abi depends on llvm.<br>
        * both llvm and libc++abi dependent on a libdemangle.<br>
        * we keep a file in both repositories.<br>
        * we have two independent implementations.</p>
      <p dir="ltr">The first 3 introduce annoying dependencies. The last
        one means the llvm demangler can have a nice interface
        (stringref), but duplicates a lot of code.</p>
      <p dir="ltr">Having a file that is copied in both repositories is
        the least horrible option IMHO. Having said that, any solution
        where lld on windows can demangle itanium  names would work for
        us.</p>
    </blockquote>
    I agree that duplication isn't ideal.  I also agree that it's
    probably the best option here.  I think option 4 naturally turns
    into option 5 over time, and in this situation, I think that is also
    fine (though annoying).<br>
    <br>
    <blockquote
cite="mid:CAG3jReJbLu_isB0A8cP+P_bCuSzMJPcYNm=0uGQvLEv7mKrZeA@mail.gmail.com"
      type="cite">
      <p dir="ltr">Cheers,<br>
        Rafael</p>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Aug 24, 2016 1:16 PM, "Mehdi Amini"
          <<a moz-do-not-send="true"
            href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>>
          wrote:<br type="attribution">
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
            > On Aug 24, 2016, at 9:56 AM, Craig, Ben <<a
              moz-do-not-send="true"
              href="mailto:ben.craig@codeaurora.org">ben.craig@codeaurora.org</a>>
            wrote:<br>
            ><br>
            > On 8/24/2016 11:31 AM, Rafael Espíndola wrote:<br>
            >>> 1. I think there are already too many build
            time dependencies crossing the compiler / runtime boundary. 
            I'm tired of my libcxx and libcxxabi builds failing because
            of unrelated cmake changes in LLVM.  To avoid that, I could
            build a standalone version... but now that won't be easily
            possible because of this change.<br>
            >> Not sure I follow. Note that this function is in an
            independent<br>
            >> library with no dependencies.<br>
            >><br>
            >>> Building libcxx and libcxxabi shouldn't require
            me to pull down llvm sources, or to have a "dev" install of
            llvm, and this change makes that problem even worse than it
            already is.  Will this even work for the cross compilation
            cases?<br>
            >> This should not change this case at all. This just
            adds a file to llvm<br>
            >> itself. In a future change I will add a ifdef to it
            so that it can<br>
            >> also be used with no changes in libcxxabi.<br>
            > I guess I'm protesting the future change, rather than
            this change. libc++abi should not use source files, header
            files, static libraries, or shared objects that come from
            the llvm repository.<br>
            <br>
            That's bothering: it means that any functionality has to be
            reimplemented (can’t use simple StringRef or Twine helper,
            which is annoying when doing string processing like here).<br>
            <br>
            —<br>
            Mehdi<br>
            <br>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
  </body>
</html>