<div class="gmail_quote">On Thu, May 31, 2012 at 1:13 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 31 May 2012 05:02, Alexey Samsonov <<a href="mailto:samsonov@google.com">samsonov@google.com</a>> wrote:<br>
> Hi,<br>
><br>
> tl;dr How can I include LLVM headers and use code from libLLVM*.a files when<br>
> building compiler-rt libraries?<br>
<br>
</div>LLVM and compiler-rt  have different licenses (compiler-rt is dual<br>
licensed with the MIT license). Would that be a problem?<br></blockquote><div><br></div><div>This is a good point...</div><div><br></div><div>Chris, I'm wondering whether putting all of the runtimes into 'compiler-rt' is really the best structure at this point... What would seem a somewhat less awkward fit to me these days:</div>
<div><br></div><div>- a runtimes project which contains various runtime libraries, under the usual LLVM license</div><div>- the original 'compiler-rt' bits either as a sub-library of this which happens to be buildable stand-alone and dual-licensed, or as its own entirely separate project</div>
<div>- coverage profile runtime, asan, tsan, and common runtime libraries separated out from compiler-rt</div><div><br></div><div><br></div><div>We can achieve the same technical result with the current structure, but its inverted and awkward: the restrictive rules (dual license / stand-alone build) are enforced in an outer layer, with the permissive rules returning in an inner layer (the asan or tsan runtimes themselves).</div>
<div><br></div><div>Thoughts?</div><div><br></div><div>If this is the direction to go, I'm happy to do the lion share of leg work to re-organize (with the help of ASan folks)... I think my personal preference would be for compiler-rt to be a separate top-level project from a generic 'runtimes' project.</div>
</div>