<p dir="ltr">Hey,</p>
<p dir="ltr">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.<br>
On the other hand, putting the symbolizer into llvm/utils (same should be for tools/) with a small Makefile worked like a charm.<br>
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?</p>
<div class="gmail_quote">On Aug 28, 2012 3:59 PM, "Alexey Samsonov" <<a href="mailto:samsonov@google.com">samsonov@google.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Aug 27, 2012 at 11:59 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

A couple of high-level points:<div><br></div><div>- 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'.</div>

</blockquote><div><br></div><div>Okay.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>- 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...</div>


</blockquote></div><br>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?<div>

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.<br>

<div><br></div><div>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? :)<br>

<div><div><div><div><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></div></div></div></div></div>
</blockquote></div>