<div dir="ltr"><div dir="ltr">On Wed, Feb 13, 2019 at 6:58 PM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 13, 2019 at 3:15 PM Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">The context is <a href="https://reviews.llvm.org/D58157" target="_blank">https://reviews.llvm.org/D58157</a></div><div dir="ltr"><br></div><div>Back when Mehdi originally introduced the LLVM_ENABLE_PROJECTS cmake variable, people were discussing the idea of folding clang-tools-extra into clang, if we moved to multiple git repos away from a monorepo. To support that goal, this code was added:</div><div><a href="https://github.com/llvm/llvm-project/blob/master/llvm/CMakeLists.txt#L144" target="_blank">https://github.com/llvm/llvm-project/blob/master/llvm/CMakeLists.txt#L144</a><br></div><div><div> # There is a widely spread opinion that clang-tools-extra should be merged</div><div> # into clang. The following simulates it by always enabling clang-tools-extra</div><div> # when enabling clang.</div><div> if (proj STREQUAL "clang")</div><div> set(LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../clang-tools-extra")</div><div> endif()</div></div><div><br></div><div>This makes it so that if you're building clang, you're building clang-tidy, clangd, etc. However, we have use cases where we want to check out the monorepo and just build clang, so we wanted to remove that block.</div></div></div></div></div></div></blockquote><div><br></div><div>Just to mention for completeness that the use case you mention can be supported also by:</div><div>1) building the clang target specifically: `ninja clang` </div></div></div></div></blockquote><div><br></div><div>There's no good way to say "build and test everything but clang-tools-extra", though.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>2) the same way we support building without llc/opt/... by setting -DLLVM_BUILD_TOOLS=OFF : there could be a -DCLANG_BUILD_TOOLS=OFF ; having clang-tools-extra be "part of" clang does not *forces* to build them. There are good question to ask about what the *default* should be when configuring and building clang/llvm.</div></div></div></div></blockquote><div><br></div><div>As said on the review, I'm open to that if there's a reason for that, but just using the same mechanism for clang-tools-extra that all other toplevel dirs get seems simpler.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>Having clang-tools-extra considered part of clang is something that can be evaluated separately (and I have no idea what makes sense today on this topic) than the build targets (the same way that people were afraid at the time that "monorepo" meant that we would always build everything, organize the source and the build components are somehow orthogonal concerns).<br></div></div></div></div></blockquote><div><br></div><div>As far as I know, most people working on clang and clang-tools-extra don't think this makes sense today. (I'd claim that was true 2 years ago as well.). We'll see if this thread shows differently, though.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div></div><div><br></div><div>Best,</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>The upshot is that if you use LLVM_ENABLE_PROJECTS today and you want to build clang tools, you will have to add "clang-tools-extra" to your CMake invocation after D58157 lands. We've identified the one upstream buildbot that uses this variable and plan to update it, but if you have downstream bots using this variable, you may also need to add "clang-tools-extra" to build clang-tidy & co.</div><div><br></div><div>We have some consensus that this is the direction we want to go in the code review from Sam Mccall, Shoaib, myself, and Nico, but please let us know if you think this is the wrong direction.</div></div></div></div></div></div>
</blockquote></div></div></div>
</blockquote></div></div>