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

[Reid Kleckner]

I'm in favor of splitting the code out into a new directory and using
separate libraries if we're going to do this.

Build systems should be really dumb, IMO.

On Thu, Oct 30, 2014 at 6:46 PM, Eric Christopher <echristo at gmail.com>
wrote:

> +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
>>
>
> _______________________________________________
> 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/67db777f/attachment.html>