<div dir="ltr"><div dir="ltr">On Thu, 29 Oct 2020 at 20:46, Mehdi Amini <<a href="mailto:aminim@google.com">aminim@google.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">I would propose to have the files in a separate tree from llvm/, mlir/, clang/ ; labelling these clearly as unsupported (either in the path to these files or in the README, or both), and not provide any public documentation on <a href="http://llvm.org" target="_blank">llvm.org</a> that would invite users to work with these. The readme would explain how to use them to include LLVM as a dependency to an existing Bazel project and document the intent as such.<br></div></div></blockquote><div><br></div><div>Sounds good, with the addendum below:</div><div><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><div class="gmail_quote"><div>This is a fair concern: can we defend against this with a clear policy?<br></div><div>Also: no public bot with Bazel or other build system than CMake should help right?</div></div></div></blockquote><div><br></div><div>Right, as you said later, no emails from broken bots, ie. people that use non-CMake build systems are expected to fix their own builds, even if the breakage came from a third-party change.</div><div><br></div><div>Of course, we expect other contributors to help with what they can, but it's not their responsibility. Such is the cost of having a different build system.</div><div><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 class="gmail_quote"><div>My intuition was that by having the file upstream, we would instead encourage such users to track the HEAD of our main branch more closely and so provide them an easier path for upstream work.  The fact that they can get upstream working with their build environment may provide an incentive to upstream along the way, even if they have to do the CMake integration first.<br></div></div></div></blockquote><div><br></div><div>The benefit to keep the files in LLVM is clear to all Bazel users out there. I don't think that's a problem for the rest of LLVM.</div><div><br></div><div>My point was that the reason why Arm's patch (128-bit) was "uncontributable" was because their build system was so different, it was impossible to keep both versions on their merged tree. This is a big problem to the Bazel users, not CMake users.</div><div><br></div><div>If we keep the policy of "not my problem", I don't see a single problem to CMake users. But that's slightly unfriendly to people that came later to LLVM and "didn't know better" before creating a whole project in Bazel, etc.</div><div><br></div><div>I'm strictly not thinking about myself here.</div><div><br></div><div>--renato</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 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">
</blockquote></div></div>
</blockquote></div></div>