<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I was looking this morning at supporting out-of-tree tools, and it is actually already there today. If you add a directory under tools that has a CMakeLists.txt file it will get picked up and added as long as LLVM_INCLUDE_TOOLS isn’t set to “bootstrap-only” (which is a dirty hack that needs to die). This happens through a call to add_llvm_implicit_external_projects().<div class=""><br class=""></div><div class="">There are some more bells and whistles I’d like to add in this area, but it is functional today.</div><div class=""><br class=""></div><div class="">-Chris<div class=""><br class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Jun 19, 2015, at 9:59 AM, Chris Bieneman <<a href="mailto:beanz@apple.com" class="">beanz@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Supporting out-of-tree tools without needing to modify the in-tree CMake code is something I’ve been thinking about adding to the CMake build system (we already support this for projects, but I was thinking about doing it differently for tools). I’ve written loads of internal tools, and it is obnoxious to have out-of-tree modifications to the CMakeLists files.<div class=""><br class=""></div><div class="">The idea I had for tools was to do something similar to the globing Chandler posted out in projects/CMakeLists.txt, but to treat globed external projects more like how we treat Polly; off by default and requiring a setting to enable them.</div><div class=""><br class=""></div><div class="">-Chris<br class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 19, 2015, at 8:07 AM, mats petersson <<a href="mailto:mats@planetcatfish.com" class="">mats@planetcatfish.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On 19 June 2015 at 15:57, Mehdi Amini <span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Hi,<div class=""><br class=""></div><div class="">If you just want to *link* to LLVM, it is not clear to me why you are not just relying on LLVM being built separately and have your project CMake pointing to the llvm build directory and using llvm-config to populate the linker argument? </div><div class=""><br class=""></div><div class="">Best,</div><div class="">— </div><span class="HOEnZb"><font color="#888888" class=""><div class="">Mehdi</div></font></span></div></blockquote><div class=""><br class=""></div><div class="">This is what I do in my Pascal compiler project. It may not be the perfect solution, but I have not found any HUGE drawback yet.<br class=""><br class="">--<br class=""></div><div class="">Mats <br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class="h5"><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 19, 2015, at 7:38 AM, John Criswell <<a href="mailto:jtcriswel@gmail.com" target="_blank" class="">jtcriswel@gmail.com</a>> wrote:</div><br class=""><div class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="">Dear All,<br class="">
<br class="">
Thanks for the feedback.<br class="">
<br class="">
To clarify, this is for LLVM-related projects that are linking
against the LLVM libraries.<br class="">
<br class="">
The feature for keeping our source code in arbitrary locations
isn't something we need. If we can just drop our source code into
llvm/projects (or some other designated LLVM subdirectory) and
write LLVM-esque CMake files, that should be enough for projects
that don't need to patch the existing LLVM tools.<br class="">
<br class="">
Regards,<br class="">
<br class="">
John Criswell<br class="">
<br class="">
<br class="">
On 6/18/15 9:06 PM, Chandler Carruth wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Thu, Jun 18, 2015 at 5:50 PM Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank" class="">hfinkel@anl.gov</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is
also related to the metapoint that the cmake build system
doesn't glob for source files (or anything else), unlike the
makefile build system. This is understandable given the
constraints, but we might want to restore some of that
functionality for the purpose of supporting out-of-tree
projects.<br class="">
</blockquote>
<div class=""><br class="">
</div>
<div class="">I actually think these are completely separate. See
below.</div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
What I mean specifically, is that, for example, we could
have a normally-empty directory tools/extensions, and
tools/CMakeLists.txt could glob for directories in
tools/extensions and call add_llvm_tool_subdirectory on all
of them. It is true that you'd need to re-run cmake whenever
you added something there (we could have a README in that
directory to remind people of that), but that seems like a
much smaller price than having to maintain a patched version
of the upstream sources.<br class="">
</blockquote>
<div class=""><br class="">
</div>
<div class="">We already do this in numerous places. See
projects/CMakeLists.txt which does exactly this.</div>
<div class=""><br class="">
</div>
<div class="">We don't automatically support external projects *in
different locations* through globbing, but that's because
that doesn't make any sense.</div>
<div class=""><br class="">
</div>
<div class="">We can add globbing-based recursion to subproject CMake
files anywhere it is useful.</div>
<div class=""><br class="">
</div>
<div class="">There is no problem with globbing to add subdirectories
IMO because subdirectories *with new CMake files* clearly
have to be introduced and maintained at the points you run
the 'cmake' tool. Only globbing for *source files* seems
problematic to me at all.</div>
<div class=""><br class="">
</div>
<div class="">-Chandler</div>
</div>
</div>
<br class="">
<fieldset class=""></fieldset>
<br class="">
<pre class="">_______________________________________________
LLVM Developers mailing list
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br class="">
<br class="">
<pre cols="72" class="">--
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cs.rochester.edu_u_criswell&d=AwMD-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=4OeKj9B2JjfLUvqRMUSgftUrExBMlakSczNUQb3B5bU&s=D5Q1Ase7UHtkcpB-jO-JMfUNW5BFFSp0eCBvoOMEc70&e=" target="_blank" class="">http://www.cs.rochester.edu/u/criswell</a></pre>
</div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></div></blockquote></div><br class=""></div></div></div></div><br class="">_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" rel="noreferrer" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class="">
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class="">
<br class=""></blockquote></div><br class=""></div></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></div></blockquote></div><br class=""></div></div></div></body></html>