<div dir="ltr">Hi Neil,<div><br></div><div>I admit that at this point I haven't considered the implications of the license MPFR is under, and at the moment I'm sticking my head in the sand until and unless we want to go down this path.</div><div><br></div><div>My expectation is that we would use their exposed API - so we'd #include <mpfr.h> and use functions from there, linking against -lmpfr and -lgmp. I admit that this option would indeed add another dimension to the testing matrix.</div><div><br></div><div>Do you have an alternative solution or a preferred solution of those I enumerated earlier?</div><div><br></div><div>Cheers,</div><div><br></div><div>James</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 4 Apr 2016 at 15:24 Neil Henning <<a href="mailto:llvm@duskborn.com">llvm@duskborn.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Hey James,<br>
<br>
I really fundamentally dislike libMPFR.<br>
<br>
License of the codebase aside, would a dependency be on the built
.so, or would it be that we'd want to pull in the code and build
that?<br>
<br>
My worry if we do bring it in even as a soft dependency is how is
this figured out - is it a case that CMake will, if it finds the .so
on the system, use and link against it? I worry that we are
introducing another matrix of potential failures if the lib is
present or not.<br>
<br>
Cheers,<br>
-Neil.</div><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<div>On 04/04/16 15:19, James Molloy wrote:<br>
</div>
<blockquote>Hi Neil,
<div><br>
</div>
<div>> Please not (1).<br>
</div>
<div><br>
</div>
<div>Could you please elaborate on your concern a bit more?</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>James</div>
</blockquote>
</div></blockquote></div>