<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 29, 2020 at 12:49 PM Renato Golin <<a href="mailto:rengolin@gmail.com">rengolin@gmail.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">On Thu, 29 Oct 2020 at 19:16, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@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">I /believe/ the idea is that, like gn, there are folks maintaining these build systems out of tree anyway - and having them in tree makes it easier to coordinate that effort, with the express intent of not burdening the general community with their upkeep (like gn currently - the idea is that there's no burden on developers to update gn build files (& consequently bazel build files)).<br></div></div></blockquote><div><br></div><div>Perhaps the initial assumption about my concerns weren't well articulated. </div><div><br></div><div>I get that those files would be "additional" and other developers won't need to care much about them. </div><div><br></div><div>But what happens when people join the project with experience in Bazel and, instead of building pure LLVM with CMake, they start using Bazel for everything, just because they're used to it?</div></div></div></blockquote><div><br></div><div>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">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.</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><br></div><div>Bazel is big enough (at least inside Google) that the probability of that happening is not trivial.</div><div><br></div><div>What if they create sub-projects that can only build with Bazel? Do we refuse inclusion? But don't we have Bazel files already?</div></div></div></blockquote><div><br></div><div>This is a fair concern: can we defend against this with a clear policy?</div><div>Also: no public bot with Bazel or other build system than CMake should help right?</div><div> </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>One big example is Android. They used to build LLVM in a very different way, and the inclusion of run-time library files was completely different. So different it was not possible to merge some changes they had (128 bit maths IIRC) because of the amount of work required.</div><div><br></div><div>My point is that adding another build system will not necessarily improve the chances of external people contributing to LLVM if they use those build systems. It may very well *reduce* those chances.</div></div></div></blockquote><div><br></div><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.</div><div>Ultimately while this may facilitate people to go in one direction or another, I suspect they would just reinforce their natural tendency: people interested in working more upstream will have a better path, and people who have less of this tendency may also have an easier path of integration. </div><div> <br></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>Once we get to the point where Bazel support is "complete" enough, and enough other projects that use LLVM use Bazel (I assume many internal Google projects), the problem I describe above is bound to happen sooner or later.</div><div><br></div><div>Personally, I'm happy to ignore Bazel and continue using CMake. But I just wanted to make clear that in the past, using a different build system did not increase the chances of contribution, so that's not a given in this case either.</div><div><br></div><div>cheers,</div><div>--renato</div></div></div>
</blockquote></div></div>