<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 8, 2017 at 11:05 AM, George Karpenkov via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From my understanding, the entire file `compiler-rt/cmake/modules/<wbr>CompileRTCompile.cmake` is dedicated to using the trick<br>
of using the just-built-compiler for compiling the sources.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Copying it seems suboptimal.<br></blockquote><div><br></div><div>Yes, copying large chunks of cmake is bad. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I can move it to `llvm/cmake/modules`, but that would be one step away from the ability to built `compiler-rt` without the parent repository.<br>
Should that matter?<br></blockquote><div><br></div><div>This is where my cmake knowledge ends, perhaps more knowledgeable folks could comment. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> not build at all<br>
<br>
Why not? libfuzzer itself does not require instrumentation (at least from my understanding),<br></blockquote><div><br></div><div>libFuzzer usually does not need instrumentation, but if one wants to couple it with msan -- then it has to be instrumented. </div><div>Maybe it's ok to build libFuzzer w/o its tests -- just need to remember that the result is untested.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
the actual problem arises with tests.<br>
<div class="HOEnZb"><div class="h5"><br>
> On May 2, 2017, at 9:34 PM, Justin Bogner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> writes:<br>
>> On Tue, May 2, 2017 at 4:28 PM, Kostya Serebryany via llvm-dev <<br>
>> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>>> On Tue, May 2, 2017 at 12:26 PM, George Karpenkov <<a href="mailto:ekarpenkov@apple.com">ekarpenkov@apple.com</a>><br>
>>> wrote:<br>
>>><br>
>>>> From my understanding, all these problems can be solved entirely<br>
>>>><br>
>>> by moving libfuzzer to compiler-rt, where (other) sanitizers already<br>
>>>> reside.<br>
>>>><br>
>>><br>
>>> Yes, that might be a reasonable thing to do.<br>
>>> I am trying to remember the reasons why we've put libFuzzer into llvm and<br>
>>> not into compiler-rt in the first place, and failing to do so.<br>
>>><br>
>><br>
>> IIRC you thought libFuzzer would be more tightly coupled to LLVM<br>
>> instrumentation, so the goal was to reap monorepo-like productivity<br>
>> developments without waiting for it to happen?<br>
>><br>
>> Maybe it was a licensing concern, UIUC vs dual UIUC/MIT?<br>
>><br>
>><br>
>>> Any thoughts on the suggestion?<br>
>>>><br>
>>>> It would be still possible to compile just libfuzzer with no<br>
>>>> dependencies, by simply making a partial checkout from SVN,<br>
>>>> and only the repo path would change.<br>
>>>><br>
>>><br>
>>> This would cause some annoyance for me and maybe some users, but nothing<br>
>>> we can't tolerate.<br>
>>> Still what are our other options?<br>
>>><br>
>>> * wait for the mono repo to happen, then we'll be able to make libFuzzer<br>
>>> depend on clang. (Or no?)<br>
>>> * move libFuzzer to a separate repo, parallel to compiler-rt? (not a large<br>
>>> win, just listing as a choice)<br>
>>> * anything else?<br>
>>><br>
>>> Does anyone see good reasons why libFuzzer should remain in llvm repo (as<br>
>>> opposed to moving it to compiler-rt)?<br>
>>><br>
>><br>
>> I'd like to move libFuzzer out of llvm/lib/, since it's definitely a<br>
>> runtime library, and not compiler library infrastructure. compiler-rt seems<br>
>> like the best place to put it for now, unless there are licensing concerns.<br>
><br>
> Maybe we should just move it under llvm/runtimes and set it up with a<br>
> fairly simple cmake config? I think this makes it pretty trivial to<br>
> build it with the just-built clang. It doesn't have terribly much to do<br>
> with compiler-rt IMO - this isn't something that enables a compiler<br>
> feature per se, it's more of its own thing.<br>
><br>
>> Mechanically, we can do this in one history-preserving commit by checking<br>
>> out the entire SVN repo the way that the git-llvm script does. SVN users<br>
>> and users of <a href="https://github.com/llvm-project/llvm-project" rel="noreferrer" target="_blank">https://github.com/llvm-<wbr>project/llvm-project</a> will still see<br>
>> the right history. The final monorepo will presumably also have accurate<br>
>> history.<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>