<div dir="ltr">I'm somewhere in the middle.  I don't think we need to maintain build files, documentation, upstream buildbots etc for using LLVMSupport out of tree, but I do like the conceptual separation and I think "is this useful outside of LLVM" is a good conceptual litmus test for what should go in such a hypothetical library.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, May 31, 2017 at 9:36 PM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-05-31 17:11 GMT-07:00 Michael Spencer <span dir="ltr"><<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span><div><div class="m_815466825781817808m_-7808396159957260376gmail_signature">On Mon, May 29, 2017 at 10:22 AM, Mehdi AMINI via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div></span><div class="gmail_quote"><span><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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="m_815466825781817808m_-7808396159957260376gmail-">2017-05-29 9:25 GMT-07:00 Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span>:<br><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"><span><div><div class="gmail_quote"><div>On Sun, May 28, 2017 at 8:54 PM Mehdi AMINI via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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><div>2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev <span><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time.<div><br></div><div>The real culprit here is tablegen.  Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn't?</div></div></blockquote><div></div></div><div><br></div></div><div><div>Splitting ADT just based on tablegen usage seems dubious to me. If we need to go this route, I'd replace as many uses of ADT data structure with STL ones to begin with to reduce the surface.</div></div></blockquote><div><br></div></div></div></span><div><div class="gmail_quote"><div>Tablegen would not need to determine WHERE to split, it would just motivate the why.</div></div></div></div></blockquote><div><br></div></span><div>Well even the why :)</div><div>(note I was mentioning ADT and not Support above).</div><span class="m_815466825781817808m_-7808396159957260376gmail-"><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><div class="gmail_quote"><div>  It's obvious just from looking at Support's include directory though that a lot of stuff in there doesn't belong together.  A quick look over the include directory already suggests a split into "broadly useful stuff" and "narrowly useful stuff"</div></div></div></div></blockquote><div><br></div></span><div>I agree, Support is a mess IMO (we have target specific stuff here just for the sake of sharing code with clang AFAIK) and I'm not sure anyone would oppose to split it. Ideally the way I would split it would be such that it could (at some point) be useful outside of LLVM (just like ADT), so one main criteria could be "could this component of Support be useful outside of LLVM (and its subprojects)".</div></div></div></div></blockquote><div><br></div></span><div>While it would be nice to easily use parts of support outside of llvm (as I've done on many occasions), I'm not sure the llvm project wants to maintain and support a generic c++ library. </div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Sorry, I'm not sure to follow you, because my impression is that we're *already* maintaining a generic C++ library in-tree. The fact that the mess that is libSupport today does not allow to split ADT (or other generic utilities in libSupport) out-of-tree easily does not change that.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Given that I don't think use outside of llvm is a great line to split on.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I think on the opposite that it is a valuable line because it matches a conceptual layer.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div></div></div></blockquote></div>