<div dir="ltr">On Wed, Aug 21, 2013 at 6:27 PM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank" class="cremed">hans@chromium.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Aug 21, 2013 at 5:22 PM, Hans Wennborg <<a href="mailto:hans@chromium.org" class="cremed">hans@chromium.org</a>> wrote:<br>

> On Wed, Aug 21, 2013 at 3:55 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="cremed">chandlerc@google.com</a>> wrote:<br>
>><br>
>> On Wed, Aug 21, 2013 at 3:50 PM, Hans Wennborg <<a href="mailto:hans@chromium.org" class="cremed">hans@chromium.org</a>> wrote:<br>
>>><br>
>>> $ diff --unified /tmp/library.txt /tmp/all.txt | grep -e "^+"<br>
>>> +++ /tmp/all.txt        2013-08-21 15:22:31.163831100 -0700<br>
>>> +./bin/clang-tblgen.exe<br>
>>> +./bin/llvm-lit<br>
>>> +./bin/llvm-tblgen.exe<br>
>>> +./share<br>
>>> +./share/llvm<br>
>>> +./share/llvm/cmake<br>
>>> +./share/llvm/cmake/AddLLVM.cmake<br>
>>> +./share/llvm/cmake/AddLLVMDefinitions.cmake<br>
>>> +./share/llvm/cmake/ChooseMSVCCRT.cmake<br>
>>> +./share/llvm/cmake/GetSVN.cmake<br>
>>> +./share/llvm/cmake/HandleLLVMOptions.cmake<br>
>>> +./share/llvm/cmake/LLVM-Config.cmake<br>
>>> +./share/llvm/cmake/LLVMConfig.cmake<br>
>>> +./share/llvm/cmake/LLVMConfigVersion.cmake<br>
>>> +./share/llvm/cmake/LLVMParseArguments.cmake<br>
>>> +./share/llvm/cmake/LLVMProcessSources.cmake<br>
>>> +./share/llvm/cmake/TableGen.cmake<br>
>>><br>
>>><br>
>>> Note that FileCheck, count, not, et al. are not installed, and they<br>
>>> never were (my "all" variant is equivalent to our current install<br>
>>> target). I should have noticed that earlier :/<br>
>><br>
>><br>
>> Interesting!<br>
>><br>
>>><br>
>>><br>
>>> The cmake files are needed if someone builds e.g. Clang out-of-tree<br>
>>> against the LLVM install dir.<br>
>>><br>
>>> I don't think it makes sense to install llvm-tblgen and clang-tblgen<br>
>>> at all. (Maybe it made sense before, when clang used llvm's tablegen).<br>
>>><br>
>>> Given the above, would it make sense to merge #1 and #2?<br>
>><br>
>><br>
>> Quite possibly... Can we avoid installing llvm-lit as well? (probably ask<br>
>> Jordan?) If so, then SGTM.<br>
><br>
> Yes, I believe so. After chatting with Michael, I don't think there<br>
> are builds that rely on llvm-lit being installed.<br>
><br>
> I'd like to go ahead and start this off by removing llvm-lit and the<br>
> tablegens from the install (patch attached) to make sure nothing<br>
> breaks and no one gets upset. OK to commit?<br>
<br>
</div></div>Actually, let's start with removing only llvm-lit.<br></blockquote><div><br></div><div>LGTM, please commit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Turns out clang (and lld too) depends on llvm-tblgen for generating<br>
the option parsing tables. It even uses the existence of llvm-tblgen<br>
to detect a valid "build or install" directory for llvm :/<br></blockquote><div><br></div><div>It would seem better to use llvm-config.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess one could argue that the option parsing stuff, including<br>
generating the tables, is part of llvm's functionality as a library.<br>
The rests of what llvm-tblgen does seems pretty internal to llvm<br>
though.<br>
</blockquote></div><br></div><div class="gmail_extra">I think it is all internal. The option parsing stuff is definitely internal. I think that clang and lld should use llvm-tblgen (if they need it) out of the llvm build tree just like they use lit out of that tree. I think they can find it with llvm-config?</div>
</div>