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

[Chandler Carruth]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141020/703bc5bd/attachment.html>