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

[Alexander Potapenko]

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.
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?
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121106/1b601436/attachment.html>