[llvm-dev] moving libfuzzer to compiler-rt?

[George Karpenkov via llvm-dev]

Again, after offline conversation with Chris Bieneman:

 - move to compiler-rt would be too complicated due to change in licenses
 - it would make much more sense to move to “tools” folder instead, for the following reasons:
    * conceptually, it’s a tool, not a library
    * all other projects in “lib” depend on LLVM and can not build without LLVM, libFuzzer does not
    * practically speaking, CMake has no way of knowing whether Clang is being built when
      “lib” is compiled, yet it does know for projects in tools.

Using a freshly built clang for projects in “tools” is embarrassingly easy and only requires a couple of lines
of configuration change.

Kostya, what about moving to “tools” then?

> On May 9, 2017, at 11:07 AM, Dan Liew <dan at su-root.co.uk> wrote:
> 
> On 9 May 2017 at 18:55, Kostya Serebryany <kcc at google.com <mailto:kcc at google.com>> wrote:
>> 
>> 
>> On Tue, May 9, 2017 at 10:23 AM, Dan Liew <dan at su-root.co.uk> wrote:
>>> 
>>>> Does anyone see good reasons why libFuzzer should remain in llvm repo
>>>> (as
>>>> opposed to moving it to compiler-rt)?
>>> 
>>> Does moving LibFuzzer to compiler-rt imply that it is compiled as part
>>> of compiler-rt and shipped with it?
>>> 
>>> How does that fit with LibFuzzer's model of allowing the user to
>>> provide their own `main()`.
>> 
>> 
>> libFuzzer doesn't allow users to use their own main (not any more).
>> Although I am not sure how that's related to moving libFuzzer somewhere.
> 
> Oops. That shows how long it's been since I looked at the source code.
> 
> It was related in that if LibFuzzer was shipped as part of compiler-rt
> I presumed we would need to supply both libraries to end users.
> Given that this feature was removed it is a non-issue.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170509/4982a436/attachment.html>