<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 3, 2017, at 6:09 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">llvm-profdata is part of llvm though.  It’s perfectly fine for something in clang to depend on something in llvm.  However, clang and lld are two independent llvm subprojects, neither of which can depend on each other.<br class=""><br class="">Generally speaking, from a layering perspective, if A depends on B and C, but B and C are independent, that should be reflected in the structure.<br class=""><br class="">For example, in CMake we will need to find out if lld is being built, since it is optional.  We would not be able to do this from inside of the clang tree, without requiring the parent cmake (e.g. llvm) to make sure that we traversed into lld’s cmake first.  This is a clear layering violation though.  Instead, the proper way to do it is have llvm include both, and the run the debuginfo-tests cmake configuration<br class=""></div></blockquote><div><br class=""></div>Got it, thanks.</div><div><br class=""></div><div>vedant</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Nov 3, 2017 at 6:00 PM Vedant Kumar <<a href="mailto:vsk@apple.com" class="">vsk@apple.com</a>> wrote:<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=""><blockquote type="cite" class=""><div class="">On Nov 3, 2017, at 3:21 PM, Zachary Turner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_-2490131793136289898Apple-interchange-newline"><div class=""><div dir="ltr" class="">Greetings,<div class=""><br class=""></div><div class="">If you dont' care about running debuginfo-tests, and don't maintain a bot that runs debuginfo-tests, you can stop reading.</div><div class=""><br class=""></div><div class="">I've uploaded a patch [<a href="https://reviews.llvm.org/D39605" target="_blank" class="">https://reviews.llvm.org/D39605</a>] that changes the way you run debuginfo-tests.<br class=""></div><div class=""><br class=""></div><div class="">Prior to this patch, the way to run them is to clone an external git repository into clang/test and then debuginfo-tests will happen transparently when you run "ninja check-clang".</div><div class=""><br class=""></div><div class="">After this patch, there will be two workflows depending on if you use multi-repo or mono-repo.</div><div class=""><br class=""></div><div class="">multi-repo: You will need to clone debuginfo-tests into llvm/projects, then run "ninja check-debuginfo"</div><div class=""><br class=""></div><div class="">mono-repo: pass -DLLVM_ENABLE_PROJECTS="debuginfo-tests", then run "ninja check-debuginfo"</div><div class=""><br class=""></div><div class="">The motivation for this change is that planned additions to debuginfo-tests require us to be able to make use of lld, and as a result the tests need to live somewhere that can access both clang and lld, not just clang.</div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">I'm not at all opposed to this effort, but I do wonder why this is part of the motivation. Tests in clang/test should be able to use any binary in <build-dir>/bin, right? E.g we use <build-dir>/bin/llvm-profdata for the tests in clang/test/Profile.</div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Furthermore, giving them their own target "check-debuginfo" as opposed to being transparently added to check-clang makes more sense from a usability perspective.  Finally, this new approach is mono-repo friendly whereas the previous one was not.</div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">Yep.</div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">I'm hoping this won't be too disturbing of a change, but please leave comments and issues on this thread or on the code rview.</div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">We have several bots which clone debuginfo-tests to tools/clang/test, but it shouldn't be too much of a hassle to migrate them. I've CC'd Mike and Chris as a heads-up (or in case they have anything to add :).</div><div class=""><br class=""></div><div class="">thanks,</div><div class="">vedant</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Thanks!</div></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>