<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 10:39 PM Neil Nelson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">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>
<p><font size="-1">Some good remarks Stella.<br>
</font></p>
<p><font size="-1">What does <i>second tier</i> mean?</font></p></div></blockquote><div><br></div><div>It was mainly me reaching (probably badly) for a term to sum up what others have alluded to:</div><div><ul><li>Has some level of community interest in consuming LLVM as a dep from the build setups that use it -- at least enough to commit to maintaining it in reasonably good working order.</li><li>Has no expectation of maintenance by those not associated with consuming it.</li><li>Is not distributed as part of LLVM releases.</li><li>Is not guaranteed to work at arbitrary LLVM commits.</li><li>Probably has a Discourse tag under an "Unsupported Build Systems" top-level or something. <br></li><li>Is advertised specifically as an unsupported way to take a dep on LLVM (but if you have problems, feel free to reach out to <insert discourse tag> for ad-hoc help).</li><li>Could be deleted at any time (but with notice given to users so they can take a copy with them).</li></ul></div><div> Practically, I've seen many build systems with some level of interop available with respect to their more established peers (i.e. New Build System A can source deps from Older Build System B), but often with an impedance mismatch that tends to make it suitable for relatively simple things and hard to maintain for more complicated. This is actually the case with Bazel (and based on the FB feedback, to some extent Buck) -- and can be severe enough to cause maintaining a mirror built natively for the build system worth it. This seems to impact people using "hermetic" build systems the worst because they like to have pure source deps on everything that they possibly can, and the usual escape hatches (install and point to headers/libs) don't work well for their setups for whatever reason. </div><div><br></div><div>I don't think the LLVM Project should have any obligation to keep such things running, but providing some hosting and a place to live for what amounts to real people trying to use and interact (and often contribute) to the project seems like a pretty minimal thing to provide and it helps keep the community together, even though some members have chosen to live on weird islands and like to declare dependencies on all of their headers :)</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>
<p><font size="-1">There are additional directories in the LLVM
download such as flang, compiler-rt, openmp, but these do not
seem to be second-tier though there may be a sense in which they
are.</font></p>
<p><font size="-1">Is the idea of second-tier that there will be
additional directories or programs embedded in the existing LLVM
directories not available for use to those without bazel? If
that is the case, then what is the relevance of those
contributions?</font></p>
<p><font size="-1">It seems we are saying that if a contribution is
relevant then either it is in the cmake build, making bazel
superfluous to obtain a build, or it is in a bazel-only build. A
cmake build would be required for the parts we have now and then
an additional bazel build for the second-tier parts.</font></p>
<p><font size="-1">There is talk of gn. I am not seeing gn installed
here but am not aware it is required. Is it the case that
whatever gn does, cmake does, or is it the case there is a
necessary gn build sequence in LLVM somewhere?</font></p>
<p><font size="-1">Neil Nelson<br>
</font></p>
<div><font size="-1">On 10/29/20 10:22 PM,
Stella Laurenzo via llvm-dev wrote:<br>
</font></div>
<blockquote type="cite">
<div dir="auto"><font size="-1">On to my note...</font></div>
<div dir="auto"><font size="-1"><br>
</font></div>
<div dir="auto"><font size="-1">One other cost to consider is that
if we have this outside of the monorepo, and outside of the
LLVM organization, we have a contribution barrier up which
firmly entrenches this as a "Google thing", and I don't think
that is a good thing for LLVM as a project... There will be a
different committer pool, different policy enforcement (such
as accepting Google's CLA), different comms channels, etc.
Projects, both OSS and private, outside of Google do use both
bazel and LLVM, and it would be best, in my opinion, if they
could source and contribute all of the LLVM bits from the LLVM
org, including second tier build support, where it exists (and
we should clearly cordone this off as some kind of second
tier).</font></div>
</blockquote>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>