<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jun 18, 2015 at 5:50 PM Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br></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></blockquote><div><br></div><div>I actually think these are completely separate. See below.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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></blockquote><div><br></div><div>We already do this in numerous places. See projects/CMakeLists.txt which does exactly this.</div><div><br></div><div>We don't automatically support external projects *in different locations* through globbing, but that's because that doesn't make any sense.</div><div><br></div><div>We can add globbing-based recursion to subproject CMake files anywhere it is useful.</div><div><br></div><div>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><br></div><div>-Chandler</div></div></div>