[llvm-commits] [Sanitizer] PATCH: Enable CMake build of llvm-symbolizer used by sanitizer tools

[Alexey Samsonov]

On Tue, Nov 6, 2012 at 9:36 PM, Alexander Potapenko <glider at google.com>wrote:

> Hey,
>
> I was trying to add configure+make support for llvm-symbolizer recently,
> but it turned out to be tricky, because compiler-rt doesn't provide any
> other executables yet.
> On the other hand, putting the symbolizer into llvm/utils (same should be
> for tools/) with a small Makefile worked like a charm.
>
AFAIR this should go to "tools" as "utils" are built before LLVM libraries,
and tools are built after them (and usually use them).

> Provided that llvm-symbolizer doesn't really have much to do with
> compiler-rt, won't it be better to move it to llvm/tools and have both
> cmake and configure+make work out of the box?
>
I'm all for it. Chandler, what shall we do to make it happen? :)



> On Aug 28, 2012 3:59 PM, "Alexey Samsonov" <samsonov at google.com> wrote:
>
>> On Mon, Aug 27, 2012 at 11:59 AM, Chandler Carruth <chandlerc at google.com>wrote:
>>
>>> A couple of high-level points:
>>>
>>> - I think I would prefer this to not live under the 'lib' tree in
>>> compiler-rt. I think the most consist name compared to other tools in the
>>> tree would be "utils/llvm-symbolizer", but I'm interested to hear other
>>> thoughts here. In the LLVM project itself, the "utils/..." tree is built
>>> before libraries, and can be used by them, while the "tools/..." tree is
>>> built after libraries and can use them. It seems like if this lives in
>>> compiler-rt, it should then be under a 'utils' tree, and if it ever moves
>>> into LLVM itself, it would live under 'tools'.
>>>
>>
>> Okay.
>>
>>
>>>
>>> - I think you can actually do more hackery here. ;] I think you can
>>> scrape the compile flags and definitions out of the original library rule.
>>> You should also scrape any hard dependencies that are in place for things
>>> like generated source code. That probably means your macro needs to be
>>> something more generic than just appending sources...
>>>
>>
>> Why would I need to use library-specific compiler flags / definitions if
>> I compile the sources differently and want to have control over the way I
>> do it? Not sure about hard deps on generated source code, could you please
>> elaborate on this?
>> Still, in the present situation many compiler options / definitions are
>> set not on per-file and not on per-target basis, but globally for all LLVM
>> (like __STDC_XXX=1 definitions). And they will be present in build rules
>> for compiler-rt targets (or executables like llvm-symbolizer) as well. That
>> said, I can scrape flags/definitions for libraries I want to use, but they
>> are empty.
>>
>> The long-term solution you mentioned in another thread (with several LLVM
>> build trees automatically constructed and configured for a variety of
>> targets by compiler-rt) sounds good to me and is far more superior. But do
>> we necessary have to invest in it now, skipping the phase of hackery? :)
>>
>> --
>> Alexey Samsonov, MSK
>>
>


-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121106/9955bdec/attachment.html>