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

[Alexey Samsonov]

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/20120828/5a9d37b4/attachment.html>