llvm dev - Oct 2020 - Contributing Bazel BUILD files similar to gn

I agree with Tom.  This seems like a natural time to use the decision making
process, and I encourage you to do so.  Some random points I’ve taken away from
the threads:

1) I don’t think this discussion has anything to do with the technical merits of
bazel over cmake.  There is empirically a community of people who would benefit
from this, and there is no proposal to replace cmake with bazel.  This is your
"We'll spend more time contributing to LLVM instead :-D” point.  I
would de-emphasize the technical points, because you’re not actually
evangelizing the technology here, you’re making a practical pitch.

2) I don’t think the comparison to GN is very important.  It is prior art, but
doesn’t mean that it is necessarily correlated to this decision.  However, it
doesn’t seem to me that GN has been a problem in practice for the community, so
perhaps there is something to learn from that.  For example, the
llvm/utils/GN/README.rst file clearly labels GN support as “experimental and
best effort”.  GN also seems maintained, and even has a "LLVM GN Syncbot”
that is doing stuff.

3) I think there is an important question (independent of Bazel) of “how do we
foster new things” and “how do we support things that are empirically important
to the community”?  We don’t want to burden all contributors to help out a few
of them, but keeping something “in tree” and marked experimental doesn’t seem
like a burden.

4) The big question is: Should this be in the mono-repo, a separate llvm
incubator project, or none of these?  What should the terms of support be, etc?


If you frame this carefully, I think we can make a decision quickly on this and
move on.  From my personal perspective, it seems pretty obvious that we should
take this, we just need to get the terms clear.  For example, if I check in a
cmake change and break a bazel builder, I shouldn’t be on the hook to fix it,
and arguably shouldn’t even get emailed about it.

-Chris


> On Oct 30, 2020, at 9:42 AM, Tom Stellard via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On 10/28/20 7:18 PM, Geoffrey Martin-Noble via llvm-dev wrote:
>> Hi all,
>> tl;dr: We'd like to contribute Bazel BUILD files for LLVM and MLIR
in a side-directory in the monorepo, similar to the gn build.
> 
> Hi Geoffrey,
> 
> I think you've received some good feedback on this thread, but It also
doesn't look like continuing discussion on this thread is going to lead to a
consensus.  If you are still interested in making this change, I think it would
be best to escalate this proposal into a "proposal pitch" described
here[1].
> 
> There is also a template here[2] you can use.
> 
> [1]
https://github.com/llvm/llvm-www/blob/master/proposals/LP0001-LLVMDecisionMaking.md
> [2]
https://github.com/llvm/llvm-www/blob/master/proposals/LP0000-Template.md
> 
> -Tom
> 
>> Some of us have been working on open-source Bazel BUILD files for the
LLVM Project. You may have seen us hanging out in the #build-systems discord
channel. As you may know, Google uses Bazel internally and has maintained a
Bazel BUILD of LLVM for years. Especially with the introduction of MLIR,
we've got more and more OSS projects with a Bazel BUILD depending on LLVM
(e.g. IREE <https://github.com/google/iree>and TensorFlow
<https://github.com/tensorflow/tensorflow>). We're also not the only
ones using Bazel: e.g. PlaidML also has a Bazel BUILD of LLVM that they've
borrowed from TF
<https://github.com/plaidml/plaidml/blob/master/vendor/llvm/llvm.BUILD>.
Each of these projects has to jump through some weird hoops to keep their
version of the Bazel BUILD files in sync with the code, which requires some
fragile combination of scripts and human intervention. Instead, we'd like to
move general-purpose Bazel BUILD files into the LLVM Project monorepo. We expect
to follow the model of the GN build where these will be maintained by interested
contributors rather than expecting the general community to maintain them.
>> To facilitate and test this we've been developing a standalone
repository that just has the Bazel BUILD files. It symlinks together the
directory trees on top of a submodule as we would need in the monorepo to to
avoid in-tree BUILD files. The configuration is at
https://github.com/google/llvm-bazel. We now have those in a good place and
think they would be useful upstream.
>> # Details
>> ## What
>> Bazel BUILD files for the LLVM, MLIR, and Clang (PR out for review
<https://github.com/google/llvm-bazel/pull/72>) subprojects, potentially
expanding to others, as needed. Basically everything currently at
https://github.com/google/llvm-bazel.
>> ## Where
>> In https://github.com/google/llvm-bazelthe BUILD files live in a single
directory tree matching the structure of the overall llvm-project directory. For
users, @llvm-project is a single Bazel repository
<https://docs.bazel.build/versions/master/build-ref.html#repositories>that
includes both LLVM and MLIR subprojects. To maintain this structure, we would
probably want to put a `bazel` directory in the monorepo's utils directory
<https://github.com/llvm/llvm-project/tree/master/utils>, which currently
only contains a directory for arcanist. This is different from gn, which is
under the LLVM subproject's utils directory
<https://github.com/llvm/llvm-project/tree/master/llvm/utils/gn>. We could
similarly put the Bazel BUILD files under llvm/utils/bazel but have them be for
the entire llvm project (the subsets that are supported). This seems like an odd
structure to me, but I know that the CMake build for LLVM also builds the other
subprojects
<https://github.com/llvm/llvm-project/blob/529ac33197f6/llvm/tools/CMakeLists.txt#L34-L41>,
so maybe this would be preferable.
>> Alternatively we could split each subproject into a separate Bazel
repository and put the Bazel build files under each subproject. I think this
fragments the configuration of the BUILD without much benefit.
>> ## Configurations
>> We currently have configurations for Linux GCC and Clang, MacOS GCC and
Clang, and Windows MSVC. Support for other configurations can be added
as-desired, but supporting all possible LLVM build configurations is not the
goal.
>> ## Support
>> Support would be similar to the gn build. Contributors could optionally
update the Bazel BUILD files as part of their patches, but would be under no
obligation to do so.
>> ## Preserving History
>> I don't *think* the history of llvm-bazel is interesting enough to
try to merge it into the monorepo and I was planning to submit this as a single
patch, but please let me know if you disagree.
>> ## Benefits to the community
>>  *
>>    Projects that depend on LLVM and use the Bazel build system can
>>    avoid duplicating fragile effort. We'll spend more time
contributing
>>    to LLVM instead :-D
>>  *
>>    Bazel is stricter than CMake in many ways (e.g. it requires that
>>    even header dependencies be declared) and can catch layering issues
>>    very easily. There's even an optional layering_check feature we
>>    could turn on if its use would benefit the community. (though
>>    currently the existing problematic layering makes it a burden to
>>    maintain on our own). Even without that additional check, as
I've
>>    been keeping the Bazel build green, I've found and fixed a
number of
>>    layering issues in the past couple weeks (e.g.
>>    https://reviews.llvm.org/rGb49787df9a
>>   
<https://reviews.llvm.org/rGb49787df9a535f03761c340dca7ec3ec1155133d>and
>>    https://reviews.llvm.org/rGc17ae2916c
>>   
<https://reviews.llvm.org/rGc17ae2916ccf45a0c1717bd5f11598cc4fff342a>).
>> Here's a patch <https://reviews.llvm.org/D90352>adding the
Bazel build system. It's basically just `cp -r llvm-bazel/llvm-bazel
llvm-project/utils/bazel`.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Thanks for weighing in Chris :-)

Did you see Renato's thread proposing a more general policy for these sorts
of less-supported components that are closely tied to the core project? (
http://lists.llvm.org/pipermail/llvm-dev/2020-October/146249.html). I think
that is probably the more fruitful direction to take this as it seems to
also help formalize some existing practices in the LLVM ecosystem. Reading
the "pitch" process it sounds like it is targeted at cases where an
RFC has
not been successful at reaching consensus. That thread at least seems to be
heading in a direction of consensus while working out the details, so it's
not clear to me whether a pitch is necessarily required? Then again, it's a
more far-reaching policy, so I certainly wouldn't want it to be made in a
way where not everyone can see and participate. Also I think the end result
(if agreed) should be a policy documented on the LLVM website. I know one
of my frustrations when putting this RFC together was not knowing what the
general policies for this sort of thing were and just poking through the
codebase and list archive to get a general sense. Given these points,
perhaps a pitch is advisable regardless?

On Sat, Oct 31, 2020 at 12:55 PM Chris Lattner <clattner at nondot.org>
wrote:
> I agree with Tom.  This seems like a natural time to use the decision
> making process, and I encourage you to do so.  Some random points I’ve
> taken away from the threads:
>
> 1) I don’t think this discussion has anything to do with the technical
> merits of bazel over cmake.  There is empirically a community of people who
> would benefit from this, and there is no proposal to replace cmake with
> bazel.  This is your "We'll spend more time contributing to LLVM
instead
> :-D” point.  I would de-emphasize the technical points, because you’re not
> actually evangelizing the technology here, you’re making a practical pitch.
>
> Agreed. I was deliberately attempting to not get into Bazel's technical
merits. Perhaps I muddied the water a bit by mentioning Bazel catching
layering issues. I was trying to point out a way in which this would enable
those of us who already care about Bazel to leverage it to give back to the
community, which would be made more effective if this went through.

2) I don’t think the comparison to GN is very important.  It is prior
art,
> but doesn’t mean that it is necessarily correlated to this decision.
> However, it doesn’t seem to me that GN has been a problem in practice for
> the community, so perhaps there is something to learn from that.  For
> example, the llvm/utils/GN/README.rst file clearly labels GN support as
> “experimental and best effort”.  GN also seems maintained, and even has a
> "LLVM GN Syncbot” that is doing stuff.
>
> 3) I think there is an important question (independent of Bazel) of “how
> do we foster new things” and “how do we support things that are empirically
> important to the community”?  We don’t want to burden all contributors to
> help out a few of them, but keeping something “in tree” and marked
> experimental doesn’t seem like a burden.
>
> 4) The big question is: Should this be in the mono-repo, a separate llvm
> incubator project, or none of these?  What should the terms of support be,
> etc?
>
> I think Renato's RFC is doing a good job trying to answer these
questions
in a more general sense, which should help avoid us having to rehash all
this again each time :-)
>
> If you frame this carefully, I think we can make a decision quickly on
> this and move on.  From my personal perspective, it seems pretty obvious
> that we should take this, we just need to get the terms clear.
Glad to hear you're supportive. Hopefully this exercise will provide an
impetus to clear some things up in a broader sense rather than just for
this particular case.

> For example, if I check in a cmake change and break a bazel builder, I
> shouldn’t be on the hook to fix it, and arguably shouldn’t even get emailed
> about it.
>
Yes. I don't think it's even arguable. Only people who have specifically
indicated an interest in supporting the Bazel build should get any kind of
notification about it failing.
> -Chris
>
>
>
> > On Oct 30, 2020, at 9:42 AM, Tom Stellard via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > On 10/28/20 7:18 PM, Geoffrey Martin-Noble via llvm-dev wrote:
> >> Hi all,
> >> tl;dr: We'd like to contribute Bazel BUILD files for LLVM and
MLIR in a
> side-directory in the monorepo, similar to the gn build.
> >
> > Hi Geoffrey,
> >
> > I think you've received some good feedback on this thread, but It
also
> doesn't look like continuing discussion on this thread is going to lead
to
> a consensus.  If you are still interested in making this change, I think it
> would be best to escalate this proposal into a "proposal pitch"
described
> here[1].
> >
> > There is also a template here[2] you can use.
> >
> > [1]
>
https://github.com/llvm/llvm-www/blob/master/proposals/LP0001-LLVMDecisionMaking.md
> > [2]
> https://github.com/llvm/llvm-www/blob/master/proposals/LP0000-Template.md
> >
> > -Tom
> >
> >> Some of us have been working on open-source Bazel BUILD files for
the
> LLVM Project. You may have seen us hanging out in the #build-systems
> discord channel. As you may know, Google uses Bazel internally and has
> maintained a Bazel BUILD of LLVM for years. Especially with the
> introduction of MLIR, we've got more and more OSS projects with a Bazel
> BUILD depending on LLVM (e.g. IREE
<https://github.com/google/iree>and
> TensorFlow <https://github.com/tensorflow/tensorflow>). We're
also not
> the only ones using Bazel: e.g. PlaidML also has a Bazel BUILD of LLVM that
> they've borrowed from TF <
> https://github.com/plaidml/plaidml/blob/master/vendor/llvm/llvm.BUILD>.
> Each of these projects has to jump through some weird hoops to keep their
> version of the Bazel BUILD files in sync with the code, which requires some
> fragile combination of scripts and human intervention. Instead, we'd
like
> to move general-purpose Bazel BUILD files into the LLVM Project monorepo.
> We expect to follow the model of the GN build where these will be
> maintained by interested contributors rather than expecting the general
> community to maintain them.
> >> To facilitate and test this we've been developing a standalone
> repository that just has the Bazel BUILD files. It symlinks together the
> directory trees on top of a submodule as we would need in the monorepo to
> to avoid in-tree BUILD files. The configuration is at
> https://github.com/google/llvm-bazel. We now have those in a good place
> and think they would be useful upstream.
> >> # Details
> >> ## What
> >> Bazel BUILD files for the LLVM, MLIR, and Clang (PR out for review
<
> https://github.com/google/llvm-bazel/pull/72>) subprojects, potentially
> expanding to others, as needed. Basically everything currently at
> https://github.com/google/llvm-bazel.
> >> ## Where
> >> In https://github.com/google/llvm-bazelthe BUILD files live in a
> single directory tree matching the structure of the overall llvm-project
> directory. For users, @llvm-project is a single Bazel repository <
>
https://docs.bazel.build/versions/master/build-ref.html#repositories>that
> includes both LLVM and MLIR subprojects. To maintain this structure, we
> would probably want to put a `bazel` directory in the monorepo's utils
> directory <https://github.com/llvm/llvm-project/tree/master/utils>,
which
> currently only contains a directory for arcanist. This is different from
> gn, which is under the LLVM subproject's utils directory <
> https://github.com/llvm/llvm-project/tree/master/llvm/utils/gn>. We
could
> similarly put the Bazel BUILD files under llvm/utils/bazel but have them be
> for the entire llvm project (the subsets that are supported). This seems
> like an odd structure to me, but I know that the CMake build for LLVM also
> builds the other subprojects <
>
https://github.com/llvm/llvm-project/blob/529ac33197f6/llvm/tools/CMakeLists.txt#L34-L41>,
> so maybe this would be preferable.
> >> Alternatively we could split each subproject into a separate Bazel
> repository and put the Bazel build files under each subproject. I think
> this fragments the configuration of the BUILD without much benefit.
> >> ## Configurations
> >> We currently have configurations for Linux GCC and Clang, MacOS
GCC and
> Clang, and Windows MSVC. Support for other configurations can be added
> as-desired, but supporting all possible LLVM build configurations is not
> the goal.
> >> ## Support
> >> Support would be similar to the gn build. Contributors could
optionally
> update the Bazel BUILD files as part of their patches, but would be under
> no obligation to do so.
> >> ## Preserving History
> >> I don't *think* the history of llvm-bazel is interesting
enough to try
> to merge it into the monorepo and I was planning to submit this as a single
> patch, but please let me know if you disagree.
> >> ## Benefits to the community
> >>  *
> >>    Projects that depend on LLVM and use the Bazel build system can
> >>    avoid duplicating fragile effort. We'll spend more time
contributing
> >>    to LLVM instead :-D
> >>  *
> >>    Bazel is stricter than CMake in many ways (e.g. it requires
that
> >>    even header dependencies be declared) and can catch layering
issues
> >>    very easily. There's even an optional layering_check
feature we
> >>    could turn on if its use would benefit the community. (though
> >>    currently the existing problematic layering makes it a burden
to
> >>    maintain on our own). Even without that additional check, as
I've
> >>    been keeping the Bazel build green, I've found and fixed a
number of
> >>    layering issues in the past couple weeks (e.g.
> >>    https://reviews.llvm.org/rGb49787df9a
> >>   
<https://reviews.llvm.org/rGb49787df9a535f03761c340dca7ec3ec1155133d
> >and
> >>    https://reviews.llvm.org/rGc17ae2916c
> >>   
<https://reviews.llvm.org/rGc17ae2916ccf45a0c1717bd5f11598cc4fff342a
> >).
> >> Here's a patch <https://reviews.llvm.org/D90352>adding
the Bazel build
> system. It's basically just `cp -r llvm-bazel/llvm-bazel
> llvm-project/utils/bazel`.
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201031/ceb4a263/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3992 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201031/ceb4a263/attachment.bin>

On 31/10/20 20:45, Geoffrey Martin-Noble via llvm-dev
wrote:
>     For example, if I check in a cmake change and break a bazel builder,
>     I shouldn’t be on the hook to fix it, and arguably shouldn’t even
>     get emailed about it.
> 
>  
> Yes. I don't think it's even arguable. Only people who have
specifically
> indicated an interest in supporting the Bazel build should get any kind
> of notification about it failing.
Just don't change "should not" to "must not" ("by
default must not" is
fine).

I can think of the scenario where a generic Bazel change breaks a corner
case Cmake, and it's reasonable for the Bazel guys to ask for help from
the Cmake crew. That said, that scenario is probably a bug in Cmake ... :-)

Cheers,
Wol

Yes, I agree, Renato’s thread seems to be converging and seems like a productive
way to frame this!

-Chris
> On Oct 31, 2020, at 1:45 PM, Geoffrey Martin-Noble <gcmn at
google.com> wrote:
> 
> Thanks for weighing in Chris :-)
> 
> Did you see Renato's thread proposing a more general policy for these
sorts of less-supported components that are closely tied to the core project?
(http://lists.llvm.org/pipermail/llvm-dev/2020-October/146249.html
<http://lists.llvm.org/pipermail/llvm-dev/2020-October/146249.html>). I
think that is probably the more fruitful direction to take this as it seems to
also help formalize some existing practices in the LLVM ecosystem. Reading the
"pitch" process it sounds like it is targeted at cases where an RFC
has not been successful at reaching consensus. That thread at least seems to be
heading in a direction of consensus while working out the details, so it's
not clear to me whether a pitch is necessarily required? Then again, it's a
more far-reaching policy, so I certainly wouldn't want it to be made in a
way where not everyone can see and participate. Also I think the end result (if
agreed) should be a policy documented on the LLVM website. I know one of my
frustrations when putting this RFC together was not knowing what the general
policies for this sort of thing were and just poking through the codebase and
list archive to get a general sense. Given these points, perhaps a pitch is
advisable regardless?
> 
> On Sat, Oct 31, 2020 at 12:55 PM Chris Lattner <clattner at nondot.org
<mailto:clattner at nondot.org>> wrote:
> I agree with Tom.  This seems like a natural time to use the decision
making process, and I encourage you to do so.  Some random points I’ve taken
away from the threads:
> 
> 1) I don’t think this discussion has anything to do with the technical
merits of bazel over cmake.  There is empirically a community of people who
would benefit from this, and there is no proposal to replace cmake with bazel. 
This is your "We'll spend more time contributing to LLVM instead :-D”
point.  I would de-emphasize the technical points, because you’re not actually
evangelizing the technology here, you’re making a practical pitch.
> 
> Agreed. I was deliberately attempting to not get into Bazel's technical
merits. Perhaps I muddied the water a bit by mentioning Bazel catching layering
issues. I was trying to point out a way in which this would enable those of us
who already care about Bazel to leverage it to give back to the community, which
would be made more effective if this went through.
> 
> 2) I don’t think the comparison to GN is very important.  It is prior art,
but doesn’t mean that it is necessarily correlated to this decision.  However,
it doesn’t seem to me that GN has been a problem in practice for the community,
so perhaps there is something to learn from that.  For example, the
llvm/utils/GN/README.rst file clearly labels GN support as “experimental and
best effort”.  GN also seems maintained, and even has a "LLVM GN Syncbot”
that is doing stuff.
> 
> 3) I think there is an important question (independent of Bazel) of “how do
we foster new things” and “how do we support things that are empirically
important to the community”?  We don’t want to burden all contributors to help
out a few of them, but keeping something “in tree” and marked experimental
doesn’t seem like a burden.
> 
> 4) The big question is: Should this be in the mono-repo, a separate llvm
incubator project, or none of these?  What should the terms of support be, etc?
> 
> I think Renato's RFC is doing a good job trying to answer these
questions in a more general sense, which should help avoid us having to rehash
all this again each time :-)
> 
> If you frame this carefully, I think we can make a decision quickly on this
and move on.  From my personal perspective, it seems pretty obvious that we
should take this, we just need to get the terms clear.
> Glad to hear you're supportive. Hopefully this exercise will provide an
impetus to clear some things up in a broader sense rather than just for this
particular case.
>  
> For example, if I check in a cmake change and break a bazel builder, I
shouldn’t be on the hook to fix it, and arguably shouldn’t even get emailed
about it.
>  
> Yes. I don't think it's even arguable. Only people who have
specifically indicated an interest in supporting the Bazel build should get any
kind of notification about it failing.
> -Chris
> 
> 
> 
> > On Oct 30, 2020, at 9:42 AM, Tom Stellard via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> > 
> > On 10/28/20 7:18 PM, Geoffrey Martin-Noble via llvm-dev wrote:
> >> Hi all,
> >> tl;dr: We'd like to contribute Bazel BUILD files for LLVM and
MLIR in a side-directory in the monorepo, similar to the gn build.
> > 
> > Hi Geoffrey,
> > 
> > I think you've received some good feedback on this thread, but It
also doesn't look like continuing discussion on this thread is going to lead
to a consensus.  If you are still interested in making this change, I think it
would be best to escalate this proposal into a "proposal pitch"
described here[1].
> > 
> > There is also a template here[2] you can use.
> > 
> > [1]
https://github.com/llvm/llvm-www/blob/master/proposals/LP0001-LLVMDecisionMaking.md
<https://github.com/llvm/llvm-www/blob/master/proposals/LP0001-LLVMDecisionMaking.md>
> > [2]
https://github.com/llvm/llvm-www/blob/master/proposals/LP0000-Template.md
<https://github.com/llvm/llvm-www/blob/master/proposals/LP0000-Template.md>
> > 
> > -Tom
> > 
> >> Some of us have been working on open-source Bazel BUILD files for
the LLVM Project. You may have seen us hanging out in the #build-systems discord
channel. As you may know, Google uses Bazel internally and has maintained a
Bazel BUILD of LLVM for years. Especially with the introduction of MLIR,
we've got more and more OSS projects with a Bazel BUILD depending on LLVM
(e.g. IREE <https://github.com/google/iree
<https://github.com/google/iree>>and TensorFlow
<https://github.com/tensorflow/tensorflow
<https://github.com/tensorflow/tensorflow>>). We're also not the
only ones using Bazel: e.g. PlaidML also has a Bazel BUILD of LLVM that
they've borrowed from TF
<https://github.com/plaidml/plaidml/blob/master/vendor/llvm/llvm.BUILD
<https://github.com/plaidml/plaidml/blob/master/vendor/llvm/llvm.BUILD>>.
Each of these projects has to jump through some weird hoops to keep their
version of the Bazel BUILD files in sync with the code, which requires some
fragile combination of scripts and human intervention. Instead, we'd like to
move general-purpose Bazel BUILD files into the LLVM Project monorepo. We expect
to follow the model of the GN build where these will be maintained by interested
contributors rather than expecting the general community to maintain them.
> >> To facilitate and test this we've been developing a standalone
repository that just has the Bazel BUILD files. It symlinks together the
directory trees on top of a submodule as we would need in the monorepo to to
avoid in-tree BUILD files. The configuration is at
https://github.com/google/llvm-bazel
<https://github.com/google/llvm-bazel>. We now have those in a good place
and think they would be useful upstream.
> >> # Details
> >> ## What
> >> Bazel BUILD files for the LLVM, MLIR, and Clang (PR out for review
<https://github.com/google/llvm-bazel/pull/72
<https://github.com/google/llvm-bazel/pull/72>>) subprojects,
potentially expanding to others, as needed. Basically everything currently at
https://github.com/google/llvm-bazel
<https://github.com/google/llvm-bazel>.
> >> ## Where
> >> In https://github.com/google/llvm-bazelthe
<https://github.com/google/llvm-bazelthe> BUILD files live in a single
directory tree matching the structure of the overall llvm-project directory. For
users, @llvm-project is a single Bazel repository
<https://docs.bazel.build/versions/master/build-ref.html#repositories
<https://docs.bazel.build/versions/master/build-ref.html#repositories>>that
includes both LLVM and MLIR subprojects. To maintain this structure, we would
probably want to put a `bazel` directory in the monorepo's utils directory
<https://github.com/llvm/llvm-project/tree/master/utils
<https://github.com/llvm/llvm-project/tree/master/utils>>, which
currently only contains a directory for arcanist. This is different from gn,
which is under the LLVM subproject's utils directory
<https://github.com/llvm/llvm-project/tree/master/llvm/utils/gn
<https://github.com/llvm/llvm-project/tree/master/llvm/utils/gn>>. We
could similarly put the Bazel BUILD files under llvm/utils/bazel but have them
be for the entire llvm project (the subsets that are supported). This seems like
an odd structure to me, but I know that the CMake build for LLVM also builds the
other subprojects
<https://github.com/llvm/llvm-project/blob/529ac33197f6/llvm/tools/CMakeLists.txt#L34-L41
<https://github.com/llvm/llvm-project/blob/529ac33197f6/llvm/tools/CMakeLists.txt#L34-L41>>,
so maybe this would be preferable.
> >> Alternatively we could split each subproject into a separate Bazel
repository and put the Bazel build files under each subproject. I think this
fragments the configuration of the BUILD without much benefit.
> >> ## Configurations
> >> We currently have configurations for Linux GCC and Clang, MacOS
GCC and Clang, and Windows MSVC. Support for other configurations can be added
as-desired, but supporting all possible LLVM build configurations is not the
goal.
> >> ## Support
> >> Support would be similar to the gn build. Contributors could
optionally update the Bazel BUILD files as part of their patches, but would be
under no obligation to do so.
> >> ## Preserving History
> >> I don't *think* the history of llvm-bazel is interesting
enough to try to merge it into the monorepo and I was planning to submit this as
a single patch, but please let me know if you disagree.
> >> ## Benefits to the community
> >>  *
> >>    Projects that depend on LLVM and use the Bazel build system can
> >>    avoid duplicating fragile effort. We'll spend more time
contributing
> >>    to LLVM instead :-D
> >>  *
> >>    Bazel is stricter than CMake in many ways (e.g. it requires
that
> >>    even header dependencies be declared) and can catch layering
issues
> >>    very easily. There's even an optional layering_check
feature we
> >>    could turn on if its use would benefit the community. (though
> >>    currently the existing problematic layering makes it a burden
to
> >>    maintain on our own). Even without that additional check, as
I've
> >>    been keeping the Bazel build green, I've found and fixed a
number of
> >>    layering issues in the past couple weeks (e.g.
> >>    https://reviews.llvm.org/rGb49787df9a
<https://reviews.llvm.org/rGb49787df9a>
> >>   
<https://reviews.llvm.org/rGb49787df9a535f03761c340dca7ec3ec1155133d
<https://reviews.llvm.org/rGb49787df9a535f03761c340dca7ec3ec1155133d>>and
> >>    https://reviews.llvm.org/rGc17ae2916c
<https://reviews.llvm.org/rGc17ae2916c>
> >>   
<https://reviews.llvm.org/rGc17ae2916ccf45a0c1717bd5f11598cc4fff342a
<https://reviews.llvm.org/rGc17ae2916ccf45a0c1717bd5f11598cc4fff342a>>).
> >> Here's a patch <https://reviews.llvm.org/D90352
<https://reviews.llvm.org/D90352>>adding the Bazel build system.
It's basically just `cp -r llvm-bazel/llvm-bazel llvm-project/utils/bazel`.
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> > 
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201101/197627fa/attachment-0001.html>