[LLVMdev] [RFC] New ToolsSupport library for stuff that only tools need

[Eric Christopher]

+1 to this.

I'd slightly prefer a separate library (though moving the code vs not
moving the code I'm relatively apathetic about), but just because I hate
conditional compilation.

-eric

On Thu Oct 30 2014 at 5:55:59 PM Juergen Ributzka <juergen at apple.com> wrote:

> I am mostly impartial to the two proposed solutions (separate library or
> conditional compilation of the hooks into the tools). If we make it a
> library I think we should make it a convenience library that is intended to
> be used only with the tools and not an external supported library at all.
>
> -Juergen
>
> On Oct 20, 2014, at 1:02 PM, Chris Bieneman <beanz at apple.com> wrote:
>
> There is no real technical requirement for this. Currently we work around
> the signal handlers by building with ENABLE_CRASH_OVERRIDES=NO, and
> carrying along the command line parsing code and ToolOutputFile isn’t
> really a big drain.
>
> This seemed to me like the cleanest way to accomplish a goal of mine. The
> goal I have is to be able to build an LLVM dylib and llc/opt/etc from the
> same CMake invocation where the dylib does not have crash overrides and
> signal handler hooks, but the tools do.
>
> There are other ways to accomplish this, but I felt that separating
> libLLVMSupport into two libraries seemed the cleanest. An alternate
> approach that could work for me would be to have the implementation of the
> hooks only be compiled into the tools.
>
> -Chris
>
> On Oct 20, 2014, at 12:57 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
> The question I have is -- does the actual source code need to move? I'm
> wondering what aspects require a new library as opposed to different
> sequence of things happening when initializing LLVM as a library vs. as a
> tool.
>
> (We've definitely had trouble with the signal handlers ourselves, but I
> thought we had solved it by using different code paths to set everything
> else up...)
>
> On Mon, Oct 20, 2014 at 12:46 PM, Chris Bieneman <beanz at apple.com> wrote:
>
>> There are some pieces of functionality in LLVM today, that make sense for
>> tools like llc, opt, clang, but they aren't relevant for embedded uses like
>> LLVM in the JavaScript JIT. One example of this type of functionality is
>> the signal handlers.
>>
>> I'd like to propose migrating content that is specifically designed for
>> tools into a new ToolsSupport library. My initial candidates for the new
>> library would be; anything guarded by ENABLE_CRASH_OVERRIDES, and any
>> functionality specific to tools (i.e. ToolOutputFile and eventually command
>> line parsing— once it can be factored out).
>>
>> The primary goal of this is to make it easy for uses of LLVM that aren't
>> command line tools to not include functionality that isn't required for
>> that use case.
>>
>> Thoughts?
>>
>> -Chris
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141031/a0173d49/attachment.html>