[LLVMdev] [RFC] New ToolsSupport library for stuff that only tools need (original) (raw)

Chandler Carruth chandlerc at google.com
Mon Oct 20 12:57:11 PDT 2014

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 ENABLECRASHOVERRIDES, 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>

More information about the llvm-dev mailing list