[llvm-dev] RFC: Contributing Bazel BUILD files in the "peripheral" support tier

42 views
Skip to first unread message

Geoffrey Martin-Noble via llvm-dev

unread,
Nov 16, 2020, 10:02:05 PM11/16/20
to LLVM Dev
I previously proposed contributing Bazel build files to the LLVM monorepo, supported *only* by interested community members and not to interfere with or affect the existing CMake configuration. As part of that conversation, it became clear that the LLVM policies for more "peripheral" components were not clearly documented. We now have a shiny new Support Policy. Thank you, Renato for moving that forward. Please take a look at it, if you haven't already.

I would now like to re-raise the proposal to contribute Bazel build files to the LLVM monorepo. I am starting a new thread, as the last one became rather fragmented.

This build configuration would be added at the peripheral support level to a new `utils/bazel` directory. I've prepared a patch of what I am proposing to add. It includes a README indicating the level of support. It is largely a port of the Bazel build files Google uses internally and has maintained for several years.

This should have approximately the same impact on the community as the current GN build in `llvm/utils/gn` does today. That is, it should not affect anyone who doesn't care.

I've commented on the specific requirements listed in the support policy inline:

Code in this tier must:
 
* Have a clear benefit for residing in the main repository, catering to an active sub-community (upstream or downstream).
A number of projects build LLVM with Bazel (e.g. IREE, TensorFlow, PlaidML). Google also uses Bazel to build in its internal source repository. This includes a substantial number of developers and active contributors to LLVM. Adding this to the monorepo would provide a natural coordination point for these projects and avoid fragmentation (projects currently have their own copies of the BUILD files) or Google-centric governance (e.g. signing Google's CLA).
* Be actively maintained by such sub-community and have its problems addressed in a timely manner.
We can commit to maintaining and addressing issues with the configuration. Google has maintained its internal version of this configuration for a few years.
 
Code in this tier must not:
* Break or invalidate core tier code or infrastructure. If that happens accidentally, reverting functionality and working on the issues offline is the only acceptable course of action.
There should be no interaction between the Bazel build configuration and any core code or infrastructure.
* Negatively affect development of core tier code, with the sub-community involved responsible for making changes to address specific concerns.
 This should not affect development of core tier components. One reason we propose adding this to the root utils/ directory instead of under llvm/utils (where GN is located) is to avoid unnecessarily sending messages to llvm-commits. Others have raised the concern that the existence of an alternative build system might lead to lack of maintenance for the CMake build system. Given that supporting CMake will remain a requirement and maintenance of a Bazel build system will continue to happen regardless, we do not expect any significant impact in this way.
* Negatively affect other peripheral tier code, with the sub-communities involved tasked to resolve the issues, still making sure the solution doesn’t break or invalidate the core tier.
Similarly, this should have no interaction with other components in the peripheral tier. We will address conflicts if they arise. 
* Impose sub-optimal implementation strategies on core tier components as a result of idiosyncrasies in the peripheral component.
We do not expect any negative constraints on normal development of core tiers. Bazel is stricter about layering, which may help quickly identify layering issues in incoming commits.
* Have build infrastructure that spams all developers about their breakages.
Build infrastructure will be configured to only notify opted-in developers. 
* Fall into disrepair. This is a reflection of lack of an active sub-community and will result in removal.
Build bots with accompanying status badges will be prominently linked from the README. Currently a Linux/Clang build bot exists and can be easily reconfigured after the code move. A windows build bot will be added soon.
 
Code in this tier should:
* Have infrastructure to test, whenever meaningful, with either no warnings or notification contained within the sub-community.
* Have support and testing that scales with the complexity and resilience of the component, with the bar for simple and gracefully-degrading components (such as editor bindings) much lower than for complex components that must remain fresh with HEAD (such as experimental back-ends or alternative build systems).
Build bot coverage already exists and will be expanded as described above. 
* Have a document making clear the status of implementation, level of support available, who the sub-community is and, if applicable, roadmap for inclusion into the core tier.
The patch includes a README that should make the support level clear. I am happy to add additional language or take additional steps to make that more clear (e.g. adding `unsupported` to the directory path).
* Be restricted to a specific directory or have a consistent pattern (ex. unique file suffix), making it easy to remove when necessary.
All configuration is restricted to a single directory and should be trivial to remove.

A number of people raised the question of "why not a separate repository". This is indeed possible: It's what we've done with https://github.com/google/llvm-bazel, which is currently used by https://github.com/google/iree. It is significantly more infrastructure, coordination, and complexity for something that is specifically a configuration for the LLVM project itself, not its own dependent or adjacent project.

I believe this contribution will significantly improve the situation for downstream users that use Bazel while having minimal impact on the community at large.

Thanks,
Geoffrey

Tom Stellard via llvm-dev

unread,
Nov 17, 2020, 12:41:21 AM11/17/20
to Geoffrey Martin-Noble, LLVM Dev
On 11/16/20 10:01 PM, Geoffrey Martin-Noble via llvm-dev wrote:
> I previously <https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/
> > proposed contributing Bazel build files to the LLVM monorepo,
> supported *only* by interested community members and not to interfere
> with or affect the existing CMake configuration. As part of that
> conversation, it became clear that the LLVM policies for more
> "peripheral" components were not clearly documented. We now have a shiny
> new Support Policy <http://llvm.org/docs/SupportPolicy.html>. Thank you,
> Renato for moving that forward. Please take a look at it, if you haven't
> already.
>
> I would now like to re-raise the proposal to contribute Bazel build
> files to the LLVM monorepo. I am starting a new thread, as the last one
> became rather fragmented.
>
> This build configuration would be added at the peripheral support level
> <http://llvm.org/docs/SupportPolicy.html#peripheral-tier> to a new
> `utils/bazel` directory. I've prepared a patch
> <https://reviews.llvm.org/D90352> of what I am proposing to add. It
> includes a README indicating the level of support. It is largely a port
> of the Bazel build files Google uses internally and has maintained for
> several years.
>
> This should have approximately the same impact on the community as the
> current GN build in `llvm/utils/gn` does today. That is, it should not
> affect anyone who doesn't care.
>

I want to push back on this a little bit, because having the code in
tree does impact everyone, even people who don't care about it. It
increases disk usage, commit traffic, checkout times, bugzilla / issue
traffic, and CI builds to name a few things. There are costs to having
this in tree, the question (as always) is do the benefits outweigh the
costs?

(More comments below).


> I've commented on the specific requirements

> <http://llvm.org/docs/SupportPolicy.html#id2> listed in the support

> policy inline:
>
> Code in this tier must:
>
> * Have a clear benefit for residing in the main repository, catering
> to an active sub-community (upstream or downstream).
>
> A number of projects build LLVM with Bazel (e.g. IREE

> <https://github.com/google/iree>, TensorFlow
> <https://github.com/tensorflow/tensorflow>, PlaidML
> <https://github.com/plaidml/plaidml/blob/master/vendor/llvm/llvm.BUILD>). Google

Personally, I do not think we should have alternative build systems in
tree. However, I still think you should try to propose this as a pitch.
I would much rather this go through a fair process and land than for it
to be rejected based on a contentious thread.

Here is why I'm not convinced this should be in tree:

To me it's not clear why having the build files in-tree is better than
having a separate repo with an llvm-project sub-module. The in tree
bazel files will be broken from time to time, since most developers will
not be updating them, however, with the sub-module approach you can
ensure that the build will always work by pinning the llvm-bazel repo to
a known-working commit of llvm-project. Can you expand on the pros/cons
of in-tree vs out-of-tree with sub-modules.

Other concerns I have from reviewing the patch:

* It looks like there is a build configuration for at least one external
project (zlib) and possibly another (vulkan-headers?). Do we really
want to have build configurations for non-LLVM projects in our tree? Is
there any limit to the number of external projects that can and will be
added?

* There are 3 files (abi-breaking.h.cmake, config.h.cmake,
llvm-config.h.cmake) that have been copied from the llvm tree into
utils/bazel/, is there some way we can avoid carrying multiple copies of
the same file in tree?

* Similarly, there are some files that are normally generated at build
time clang/Config/config.h, llvm/Config/config.h,
llvm/Config/llvm-config.h that have been copied into utils/bazel. Is it
really necessary
to have these in tree? Especially since some of the templates, like
llvm-config.h.cmake, are also in utils/bazel?

* I still worry about the bazel files causing merging conflicts when
backported to the stable branch. If these are added to tree, could we
have a rule where commits to utils/bazel/ cannot include changes to
other files?

* If we have 2 alternative build systems in tree, what's the criteria
for adding more? Do they just need to meet the requirements of the
"peripheral support level" ? Can we continue to add new build systems
with no limit? I still think this needs to be addressed.

Expanding on this last point a little bit, this raises some larger
questions about what code should be allowed in tree. Essentially what
we have here is that a critical part of the LLVM project has been
re-implemented and is now being asked to be included in tree alongside
the original implementation (CMake). There are parts of the codebase
where this would clearly not be OK (e.g. a re-implementation of one of
the backends), but for build systems I think you can make a valid case
to either have it or not to have it.

And this is why I think it should be a pitch. In my opinion, these
kinds of higher-level decisions are better made by review managers than
by people on the mailing list.

The other nice thing about a pitch is that we don't need to spend days
arguing about this on the mailing list. You can take my feedback, think
about it, and if you think there is some validity to what I have said,
then all you need to do is update your proposal to address my concerns.
And if not, then you can just move on to the next email.

Thanks,
Tom


> I believe this contribution will significantly improve the situation for
> downstream users that use Bazel while having minimal impact on the
> community at large.
>
> Thanks,
> Geoffrey
>

> _______________________________________________
> LLVM Developers mailing list
> llvm...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Renato Golin via llvm-dev

unread,
Nov 17, 2020, 5:27:15 AM11/17/20
to Geoffrey Martin-Noble, LLVM Dev
Hi Geoffrey,

Thanks for the re-submission. 

I have some comments below that may sound negative, but they're probably just a reflection of my own ignorance. I want to make sure the submission is clear, so it can be accepted on its own right.

On Tue, 17 Nov 2020 at 03:02, Geoffrey Martin-Noble via llvm-dev <llvm...@lists.llvm.org> wrote:
 This should not affect development of core tier components. One reason we propose adding this to the root utils/ directory instead of under llvm/utils (where GN is located) is to avoid unnecessarily sending messages to llvm-commits. Others have raised the concern that the existence of an alternative build system might lead to lack of maintenance for the CMake build system. Given that supporting CMake will remain a requirement and maintenance of a Bazel build system will continue to happen regardless, we do not expect any significant impact in this way.

I was under the impression that "utils" was actually "llvm/utils", which would be in the same place as GN. I don't think we should treat GN and Bazel as different and I really wouldn't like to have a different quality control (for post commit reviews).

If the Bazel commits are too verbose (for example, committing auto-generated code), then we should really clean that up and commit the script that generates them and make that part of the build.

I understand the need to move the noise away, but move it too far away and it's no better than in a separate repo.

A number of people raised the question of "why not a separate repository". This is indeed possible: It's what we've done with https://github.com/google/llvm-bazel, which is currently used by https://github.com/google/iree. It is significantly more infrastructure, coordination, and complexity for something that is specifically a configuration for the LLVM project itself, not its own dependent or adjacent project.

I was also under the impression that one of the big reasons why we needed it to be in LLVM is that, like CMake, it needed files all over the place. This would indeed be a major infrastructure undertaking.

But given that it's all being hosted in a single directory, and outside of the LLVM tree, I really can't see what's so much harder about an extra checkout in the same tree.

I believe this contribution will significantly improve the situation for downstream users that use Bazel while having minimal impact on the community at large.

It's not clear to me yet if LLVM/Bazel is only used in Google projects or any other non-Google project. All that you listed so far seem to be exclusive to Google.

This is not a problem per se, but it does promote the idea that Google could common it up internally instead.

The main reasons why it would be upstream are that it's either a product by or requirement to the project itself, or it helps unite cross-industry collaboration that wouldn't be possible otherwise.

It's clearly not the former (and why it's in the periphery tier), but it's also not clear it's in the latter either.

cheers,
--renato

Renato Golin via llvm-dev

unread,
Nov 17, 2020, 5:52:54 AM11/17/20
to tste...@redhat.com, LLVM Dev
On Tue, 17 Nov 2020 at 05:41, Tom Stellard via llvm-dev <llvm...@lists.llvm.org> wrote:
* I still worry about the bazel files causing merging conflicts when
backported to the stable branch.  If these are added to tree, could we
have a rule where commits to utils/bazel/ cannot include changes to
other files?

That's usually the policy for other non-code changes, but I agree that with build system components, this is specially important.

Expanding on this last point a little bit, this raises some larger 
questions about what code should be allowed in tree.  Essentially what
we have here is that a critical part of the LLVM project has been
re-implemented and is now being asked to be included in tree alongside
the original implementation (CMake).  There are parts of the codebase
where this would clearly not be OK (e.g. a re-implementation of one of
the backends), but for build systems I think you can make a valid case
to either have it or not to have it.

We have examples of competing front-ends (the three different "flang" projects), middle-end infrastructure (the new pass manager), back-ends (the two arm64 targets) and build systems (automake/CMake).

But in all examples above, the sub-communities involved agreed on replacing the flang implementation (twice), concurrently developing the new pass manager and merging the two arm64 backends. We also have elected to keep CMake over automake. 

Those efforts were always with the intention to replace and not to co-exist. So none of our priors are close enough. 

However, those are all things that we have considered to be "core tier". We should now consider a "peripheral tier" that would be ok with co-existence, as long as they follow the support policy.

For your specific point about stable releases, breaking them would be a major failure to follow the policy, so we need to make sure that doesn't happen.

And this is why I think it should be a pitch.  In my opinion, these
kinds of higher-level decisions are better made by review managers than
by people on the mailing list.

There should be an 100% overlap between those two groups. :)

And their views on this subject would be invaluable to the discussion. It'd be beneficial to all if they could chime in.

The other nice thing about a pitch is that we don't need to spend days
arguing about this on the mailing list.  You can take my feedback, think
about it, and if you think there is some validity to what I have said,
then all you need to do is update your proposal to address my concerns.
And if not, then you can just move on to the next email.

That is true. It would be nice to have a document that reflects the latest updates on the discussion.

cheers,
--renato

Chris Tetreault via llvm-dev

unread,
Nov 17, 2020, 12:30:16 PM11/17/20
to Geoffrey Martin-Noble, LLVM Dev

Since this is being added within the bounds of a now-existing policy, I will withdraw my objections. Thanks for tabling discussion of adding Bazel until the policy on peripheral tier components was settled, and thanks very much to Renato for taking the initiative to push through a new policy!

 

Unfortunately, I do not know enough about Bazel to provide any sort of useful code review.

 

Thanks,

   Christopher Tetreault

Geoffrey Martin-Noble via llvm-dev

unread,
Dec 3, 2020, 7:27:36 PM12/3/20
to LLVM Dev
Apologies for the delayed response here. I was out of the "office".

Thanks for taking another look :-)

I want to respond first to the process question of pitch vs RFC. My impression was that the pitch process should be used in the case that an RFC couldn't reach consensus. I asked a few times in the last thread (https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/m/uVlV3pMTBAAJ and https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/m/wF5mu-dpBAAJ) whether I should move this to a pitch, but feel like there wasn't a clear response in the context of Renato's support tiers RFC.

It seems like Tom and Renato still disagree about whether I should move this to a pitch. I would appreciate some consensus on that point at least :-D I do see the appeal of a living document for this sort of thing, so definitely see the appeal there, but also it seems like the pitch process is a heavier-weight and more unusual one, so I was hesitant. My inclination is to continue this as an RFC unless we are unable to reach consensus on the issue as outlined in the pitch process description. It does feel like this is really not quite as big a decision as you seem to be suggesting. It's also an easily reversible one since there are no build dependencies and everything is contained.

On Mon, Nov 16, 2020 at 9:41 PM Tom Stellard <tste...@redhat.com> wrote:
> This should have approximately the same impact on the community as the
> current GN build in `llvm/utils/gn` does today. That is, it should not
> affect anyone who doesn't care.
>

I want to push back on this a little bit, because having the code in
tree does impact everyone, even people who don't care about it.  It
increases disk usage, commit traffic, checkout times, bugzilla / issue
traffic, and CI builds to name a few things.  There are costs to having
this in tree, the question (as always) is do the benefits outweigh the
costs?

Yes my apologies that this was poorly phrased. I was aiming for a pithy summary and a clear statement that our goal here is not to significantly impact contributors uninterested in Bazel. My impression is that the GN build has achieved that goal. I definitely agree that any addition to the monorepo should have a clear weighing of costs vs benefits and that the costs are never actually zero. I do think the costs here are really quite low however. I am happy to address your concerns and also think that it is important to note that if additional issues arise we are still agreeing to be on the hook for addressing them (e.g. if in practice this causes some unforseen issue with the release) and deleting this contribution if we cannot do so in a timely manner (`rm -rf utils/bazel` is all it requires).
 
Personally, I do not think we should have alternative build systems in
tree.  However, I still think you should try to propose this as a pitch.
I would much rather this go through a fair process and land than for it
to be rejected based on a contentious thread.

Here is why I'm not convinced this should be in tree:

To me it's not clear why having the build files in-tree is better than
having a separate repo with an llvm-project sub-module.  The in tree
bazel files will be broken from time to time, since most developers will
not be updating them, however, with the sub-module approach you can
ensure that the build will always work by pinning the llvm-bazel repo to
a known-working commit of llvm-project.  Can you expand on the pros/cons
of in-tree vs out-of-tree with sub-modules.

Out-of-tree with a submodule is the current approach we have with https://github.com/google/llvm-bazel. It's certainly doable, but involves quite a bit of bookkeeping to track which version corresponds to a given version of LLVM such that someone can fetch the correct configuration (you'll note that the repository has about 7k tags at the moment). To make things somewhat more complicated, the typical way to fetch something for use in Bazel is with an http_archive which requires one to specify the archive digest to avoid refetching on each build. This doesn't work particularly well with tags that change which commit they point to. I'm not saying these issues aren't solvable, but they add quite a bit of complexity.

The other point is that I think this makes contributing to the Bazel configuration quite a bit more complex because you have to apply patches across multiple repositories to also be kept in sync. Given that LLVM has a monorepo, it still seems like the logical place for a build configuration of LLVM used by multiple projects.

Other concerns I have from reviewing the patch:

It seems like these are mostly concerns with the specific implementation. Would you be alright with saving the specific details for an eventual review on the patch if this moves forward? I've made brief responses below.
* It looks like there is a build configuration for at least one external
project (zlib) and possibly another (vulkan-headers?).  Do we really
want to have build configurations for non-LLVM projects in our tree?  Is
there any limit to the number of external projects that can and will be
added?
These are dependencies of the LLVM Project and LLVM keeps its dependencies pretty tightly managed AFAIU. These configurations are also pretty trivial, "here are the source files", type things, so I think it's even a bit generous to call them configurations: we're just informing Bazel where the files are located.

* There are 3 files (abi-breaking.h.cmake, config.h.cmake,
llvm-config.h.cmake) that have been copied from the llvm tree into
utils/bazel/, is there some way we can avoid carrying multiple copies of
the same file in tree?

* Similarly, there are some files that are normally generated at build
time clang/Config/config.h, llvm/Config/config.h,
llvm/Config/llvm-config.h that have been copied into utils/bazel.  Is it
really necessary
to have these in tree?  Especially since some of the templates, like
llvm-config.h.cmake, are also in utils/bazel?

The copy here is pretty much orthogonal to the actual build configuration. The intent is to have a literal change detector test for changes to these cmake configurations, since they would invalidate assumptions in the Bazel configuration. Chandler and I went back and forth on a few different ways to do this. We can certainly look at other options. The issue is that I don't think there's actually a useful way to interpret the .cmake template files since changes to them are also made as changes to the cmake configuration and without these being in sync the files just drift. Happy to discuss other options for how to handle this. We could, for instance, have some other process that just looks at the git diff/log for these files.
 
* I still worry about the bazel files causing merging conflicts when
backported to the stable branch.  If these are added to tree, could we
have a rule where commits to utils/bazel/ cannot include changes to
other files?

I'd certainly be open to discussing restrictions that would avoid additional burden on release managers. I think that one makes contributing to the Bazel configuration more difficult because you cannot do it as part of a patch that requires a change, but if it's something that would cause issues with the release then we can avoid it. My intuition is that this wouldn't actually come up often, however. For example, just looking at the gn directory I see several commits in the last week that touch this and other files. Have you actually run into issues? Since this is unsupported the conflicts could also be resolved pretty much however you wanted (e.g. delete the conflict markers, delete the file), so they seem pretty trivial to deal with if they only happen occasionally. My preference would therefore be to see if this is actually a problem in practice before putting rules in place.


On Tue, Nov 17, 2020 at 2:27 AM Renato Golin <reng...@gmail.com> wrote:
Hi Geoffrey,

Thanks for the re-submission. 

I have some comments below that may sound negative, but they're probably just a reflection of my own ignorance. I want to make sure the submission is clear, so it can be accepted on its own right.

On Tue, 17 Nov 2020 at 03:02, Geoffrey Martin-Noble via llvm-dev <llvm...@lists.llvm.org> wrote:
 This should not affect development of core tier components. One reason we propose adding this to the root utils/ directory instead of under llvm/utils (where GN is located) is to avoid unnecessarily sending messages to llvm-commits. Others have raised the concern that the existence of an alternative build system might lead to lack of maintenance for the CMake build system. Given that supporting CMake will remain a requirement and maintenance of a Bazel build system will continue to happen regardless, we do not expect any significant impact in this way.

I was under the impression that "utils" was actually "llvm/utils", which would be in the same place as GN. I don't think we should treat GN and Bazel as different and I really wouldn't like to have a different quality control (for post commit reviews).

If the Bazel commits are too verbose (for example, committing auto-generated code), then we should really clean that up and commit the script that generates them and make that part of the build.

I understand the need to move the noise away, but move it too far away and it's no better than in a separate repo.
I am happy to put this in either location and agree it should be in the same place as GN. If we were to decide that it should go `utils/` then I would also propose we move GN to there as well. I believe the GN files were contributed prior to the existence of the monorepo, so a top-level `utils/` wouldn't have been an option. I think living under the root `utils/` directory makes more sense because these are not configurations for only the LLVM subproject (we also build MLIR and Clang with perhaps more to come). I believe it was Mehdi's suggestion that this would help mitigate some of the costs to having it in the monorepo because Tom mentioned commit list traffic as a concern. I don't think I agree that one directory up is akin to a separate repo though :-D

That said, this is a really minor point for me. I'm happy to put this wherever people prefer :-)


A number of people raised the question of "why not a separate repository". This is indeed possible: It's what we've done with https://github.com/google/llvm-bazel, which is currently used by https://github.com/google/iree. It is significantly more infrastructure, coordination, and complexity for something that is specifically a configuration for the LLVM project itself, not its own dependent or adjacent project.

I was also under the impression that one of the big reasons why we needed it to be in LLVM is that, like CMake, it needed files all over the place. This would indeed be a major infrastructure undertaking.

But given that it's all being hosted in a single directory, and outside of the LLVM tree, I really can't see what's so much harder about an extra checkout in the same tree.
Bazel *wants* the build files to be all over the place, but I've tricked it with some repository rule symlinking. That's also true of the LLVM GN configuration, I believe. My assumption is that having BUILD files actually throughout the repository would be something that would receive quite a bit of pushback and would be confusing for people who would naturally expect these BUILD files to be maintained as a supported build system. I would happily put a BUILD.bazel file at the root of each subproject and drop the symlinking madness, but I suspect this would not be embraced as a solution ;-P

I believe this contribution will significantly improve the situation for downstream users that use Bazel while having minimal impact on the community at large.

It's not clear to me yet if LLVM/Bazel is only used in Google projects or any other non-Google project. All that you listed so far seem to be exclusive to Google.

This is not a problem per se, but it does promote the idea that Google could common it up internally instead.

The main reasons why it would be upstream are that it's either a product by or requirement to the project itself, or it helps unite cross-industry collaboration that wouldn't be possible otherwise.

It's clearly not the former (and why it's in the periphery tier), but it's also not clear it's in the latter either.

I can really only speak for Google projects. I have also noticed several other Bazel build configurations in the wild, e.g. PlaidML (Intel) or this bazel_llvm project that I found after someone contributed a doc fix. I believe in the last thread someone from Facebook mentioned that Bazel build files would also be relatively easily translatable to their internal Bazel-derived build system, Buck. Someone from Lyft also expressed interest in using a Bazel build configuration if it was in-tree. But I can't really speak to the motivations, road maps, etc. for any of these people, companies, or projects (if you're reading, please chime in ;-P).

Renato Golin via llvm-dev

unread,
Dec 4, 2020, 2:31:35 PM12/4/20
to Geoffrey Martin-Noble, LLVM Dev
On Fri, 4 Dec 2020 at 00:27, Geoffrey Martin-Noble <gc...@google.com> wrote:
It seems like Tom and Renato still disagree about whether I should move this to a pitch. I would appreciate some consensus on that point at least :-D I do see the appeal of a living document for this sort of thing, so definitely see the appeal there, but also it seems like the pitch process is a heavier-weight and more unusual one, so I was hesitant. My inclination is to continue this as an RFC unless we are unable to reach consensus on the issue as outlined in the pitch process description. It does feel like this is really not quite as big a decision as you seem to be suggesting. It's also an easily reversible one since there are no build dependencies and everything is contained.

Hi Geoffrey,

I don't think we're disagreeing as much as trying to find the best way to do it.

Tom is worried on a meta level, both as cementing the precedent (GN was a trial, BAZEL makes it official) and as complicating the merge process. I agree with him 100%.

It's already complicated to make sure backports on various projects don't break other projects (especially in the core LLVM), and by adding build systems to the mix, we'd be adding a new dimension in the problem space.

I am more worried about following different paths for different build systems (non-overlapping features) and encouraging people to build with an "alternative" build system because CMake yet doesn't support something that they do.

I really don't want to get to a point where each system has a set of unique features, in which case, we'll have three "official" build systems. I know this isn't what you're proposing, but it's a likely outcome once we "support" (core or peripheral) more than one.

We have had that before with autoconf, as I mentioned. 


Out-of-tree with a submodule is the current approach we have with https://github.com/google/llvm-bazel. It's certainly doable, but involves quite a bit of bookkeeping to track which version corresponds to a given version of LLVM such that someone can fetch the correct configuration (you'll note that the repository has about 7k tags at the moment). To make things somewhat more complicated, the typical way to fetch something for use in Bazel is with an http_archive which requires one to specify the archive digest to avoid refetching on each build. This doesn't work particularly well with tags that change which commit they point to. I'm not saying these issues aren't solvable, but they add quite a bit of complexity.

Right, having the file in-tree means the history is unique and linear, and there's no need to create a map between BAZEL and LLVM revisions. This was a strong point of moving to the monorepo.

I'd certainly be open to discussing restrictions that would avoid additional burden on release managers. I think that one makes contributing to the Bazel configuration more difficult because you cannot do it as part of a patch that requires a change, but if it's something that would cause issues with the release then we can avoid it. My intuition is that this wouldn't actually come up often, however. For example, just looking at the gn directory I see several commits in the last week that touch this and other files. Have you actually run into issues? Since this is unsupported the conflicts could also be resolved pretty much however you wanted (e.g. delete the conflict markers, delete the file), so they seem pretty trivial to deal with if they only happen occasionally. My preference would therefore be to see if this is actually a problem in practice before putting rules in place.

The main problem here is backports. If there is a change in the code that "needs" a relative change in GN/BAZEL, we'll have to track both code and build system changes to make sure the patches apply correctly, and if not, apply a series of corrections on both sides to make it work. This is already fragile with just code, adding a new thread won't make it easier.

It may not currently be a problem with GN because there isn't a push-back (that I know of) if GN breaks on a stable release. 

Perhaps this could be one of the "peripheral" support contract points: stable releases are not required to make them work.

So, if a code change needs a BAZEL change and no one from the BAZEL community picks up the tab in time, it will be backported without it and BAZEL will be broken on that stable release.

I am happy to put this in either location and agree it should be in the same place as GN. If we were to decide that it should go `utils/` then I would also propose we move GN to there as well. I believe the GN files were contributed prior to the existence of the monorepo, so a top-level `utils/` wouldn't have been an option. I think living under the root `utils/` directory makes more sense because these are not configurations for only the LLVM subproject (we also build MLIR and Clang with perhaps more to come). I believe it was Mehdi's suggestion that this would help mitigate some of the costs to having it in the monorepo because Tom mentioned commit list traffic as a concern. I don't think I agree that one directory up is akin to a separate repo though :-D

I see. There is a current effort to move CMake to the root directory, so that'd be on par with GN and BAZEL. I don't mind where, as long as they're all in the same pattern.

I can really only speak for Google projects. I have also noticed several other Bazel build configurations in the wild, e.g. PlaidML (Intel) or this bazel_llvm project that I found after someone contributed a doc fix. I believe in the last thread someone from Facebook mentioned that Bazel build files would also be relatively easily translatable to their internal Bazel-derived build system, Buck. Someone from Lyft also expressed interest in using a Bazel build configuration if it was in-tree. But I can't really speak to the motivations, road maps, etc. for any of these people, companies, or projects (if you're reading, please chime in ;-P).

The purpose of this question was to understand how many new projects will want to move inside the LLVM umbrella (core, peripheral, incubator) that can only be built with BAZEL.

If we accept GN/BAZEL as a supported build system, we should still require new projects to build with CMake, in addition to their native ones, if different.

This could still "leave out" some features in the native build system (if supported) that haven't been moved to CMake, and that's how you get disjoint support levels I mentioned above.

I'm optimistically hoping that the likelihood of this happening and the number of projects will be low enough that we won't have that problem in practice.

cheers,
--renato 

Eric Christopher via llvm-dev

unread,
Dec 4, 2020, 4:41:47 PM12/4/20
to Renato Golin, LLVM Dev
Hi Renato,

As a summary: At its core I think that this is a "lowering the barrier to entry" for llvm rather than a support issue. No one is suggesting that this is supported other than by its users inside an easily removed directory similar to how a lot of specific support has been handled.

Your questions are seeming to move the bar far past what anyone is asking for and so it seems that there's a disconnect occurring here. I'll answer a few of your concerns inline.


Tom is worried on a meta level, both as cementing the precedent (GN was a trial, BAZEL makes it official) and as complicating the merge process. I agree with him 100%.


Makes what official? I think the "support" story - "there is none" - is pretty clear here. As far as merging it's pretty clear this is a "user supported" rather than "community supported" process. No one, including me, wants to add another supported llvm build system. And let's be honest, most people didn't even notice that gn was added until it was pointed out and it hasn't caused any issues. There's no assumption of anything working anywhere.
 
It's already complicated to make sure backports on various projects don't break other projects (especially in the core LLVM), and by adding build systems to the mix, we'd be adding a new dimension in the problem space.

I am more worried about following different paths for different build systems (non-overlapping features) and encouraging people to build with an "alternative" build system because CMake yet doesn't support something that they do.

I really don't want to get to a point where each system has a set of unique features, in which case, we'll have three "official" build systems. I know this isn't what you're proposing, but it's a likely outcome once we "support" (core or peripheral) more than one.

We have had that before with autoconf, as I mentioned. 


There's no notion of having official build systems here and as the previous build system maintainer and owner of autoconf I'm pretty sure this doesn't reflect how the situation was. The dual aspect of cmake and autoconf was an explicit acknowledgment that we wanted to support both in tree while we moved from one to the other. In addition, we still have the vestiges of some other build systems in tree and tools used exclusively for outside projects for simplicity.
 
I can really only speak for Google projects. I have also noticed several other Bazel build configurations in the wild, e.g. PlaidML (Intel) or this bazel_llvm project that I found after someone contributed a doc fix. I believe in the last thread someone from Facebook mentioned that Bazel build files would also be relatively easily translatable to their internal Bazel-derived build system, Buck. Someone from Lyft also expressed interest in using a Bazel build configuration if it was in-tree. But I can't really speak to the motivations, road maps, etc. for any of these people, companies, or projects (if you're reading, please chime in ;-P).

The purpose of this question was to understand how many new projects will want to move inside the LLVM umbrella (core, peripheral, incubator) that can only be built with BAZEL.


This is a different question and one I don't think we need to address, however, if it helps...

As you say here:
 
If we accept GN/BAZEL as a supported build system, we should still require new projects to build with CMake, in addition to their native ones, if different.


I would be against any project that does not build with CMake being added to the llvm project. If they want to add support (or even support another build system) to one of the optional, and unsupported, build systems then that's up to them or the people that care about those build systems. Same with editor integrations :)
 
This could still "leave out" some features in the native build system (if supported) that haven't been moved to CMake, and that's how you get disjoint support levels I mentioned above.


As I said in my intro - at its core this isn't a support issue. Adding in the capability of something being able to build with different build systems helps the llvm project both be open to new contributors and integrations. We don't need to support them more than the people care to work on it, but having the capability means that people whose primary goal is integrating llvm into various projects can have those projects' build systems live alongside our supported meta-build system. This is basically "tooling" in a directory that makes integrating with projects that depend upon llvm easier and lowers the barrier for people that work on those projects to more easily work with llvm.

I hope this helps and would be happy to continue the discussion with you either here, offline, or via video conference.

Thanks!

-eric



Renato Golin via llvm-dev

unread,
Dec 4, 2020, 6:07:51 PM12/4/20
to Eric Christopher, LLVM Dev
Hi Eric,

Sorry, my reply was a lot more "formal" than I intended. I was trying to explain the concerns to a finer level of detail than necessary, while also trying to reply to some of Tom's concerns. I wasn't successful.

I agree with your points. I think we're all clear that the expected support is user-based, as I tried to express in the "support policy". Conflicts in merges and backports are the sole responsibility of the sub-community.

I think we won't have any of the problems we discussed in practice. And if we do, we'll be able to solve them fairly quickly and painlessly.

So, just to make it clear: I don't mind Bazel in the repository at all, with the support level as discussed, but it would be nice if Bazel and GN ended up in the same place.

cheers,
--renato

Eric Christopher via llvm-dev

unread,
Dec 4, 2020, 6:26:27 PM12/4/20
to Renato Golin, Tom Stellard, LLVM Dev
Hi Renato,

On Fri, Dec 4, 2020 at 6:07 PM Renato Golin <reng...@gmail.com> wrote:
Hi Eric,

Sorry, my reply was a lot more "formal" than I intended. I was trying to explain the concerns to a finer level of detail than necessary, while also trying to reply to some of Tom's concerns. I wasn't successful.


Awesome. I'm glad to get that cleared up. I was definitely surprised by your response :)
 
I agree with your points. I think we're all clear that the expected support is user-based, as I tried to express in the "support policy". Conflicts in merges and backports are the sole responsibility of the sub-community.

I think we won't have any of the problems we discussed in practice. And if we do, we'll be able to solve them fairly quickly and painlessly.


Sweet, thanks. +Tom Stellard  any further thoughts here?
 
So, just to make it clear: I don't mind Bazel in the repository at all, with the support level as discussed, but it would be nice if Bazel and GN ended up in the same place.


I see it as a parallel directory in the same place. I'd very much prefer not to add build systems that require sprinkling files all over the source base.

Thanks!

-eric

Geoffrey Martin-Noble via llvm-dev

unread,
Dec 4, 2020, 6:47:21 PM12/4/20
to Eric Christopher, LLVM Dev
On Fri, Dec 4, 2020 at 3:26 PM Eric Christopher <echr...@gmail.com> wrote:
Hi Renato,

On Fri, Dec 4, 2020 at 6:07 PM Renato Golin <reng...@gmail.com> wrote:
Hi Eric,

Sorry, my reply was a lot more "formal" than I intended. I was trying to explain the concerns to a finer level of detail than necessary, while also trying to reply to some of Tom's concerns. I wasn't successful.


Awesome. I'm glad to get that cleared up. I was definitely surprised by your response :)
 
I agree with your points. I think we're all clear that the expected support is user-based, as I tried to express in the "support policy". Conflicts in merges and backports are the sole responsibility of the sub-community.

I think we won't have any of the problems we discussed in practice. And if we do, we'll be able to solve them fairly quickly and painlessly.


Sweet, thanks. +Tom Stellard  any further thoughts here?
 
So, just to make it clear: I don't mind Bazel in the repository at all, with the support level as discussed, but it would be nice if Bazel and GN ended up in the same place.


I see it as a parallel directory in the same place. I'd very much prefer not to add build systems that require sprinkling files all over the source base.

Agreed. And I don't care too much where that place is. I was only proposing `utils/` at the root based on some feedback complaining about mailing-list traffic and offering to propose a move of `llvm/utils/gn` to `utils/gn` as a prerequisite if that was preferred. Obviously it's easier for me to put it alongside gn in `llvm/utils/bazel`, but I thought since we were discussing this it might be a good time to consider whether that's actually the best place :-) And at some point I also mentioned that having "unsupported" somewhere in the path might help make the support status extremely clear, e.g. `utils/unsupported/[bazel|gn]`

Renato Golin via llvm-dev

unread,
Dec 4, 2020, 8:13:07 PM12/4/20
to Geoffrey Martin-Noble, LLVM Dev
On Fri, 4 Dec 2020 at 23:47, Geoffrey Martin-Noble <gc...@google.com> wrote:
Agreed. And I don't care too much where that place is. I was only proposing `utils/` at the root based on some feedback complaining about mailing-list traffic and offering to propose a move of `llvm/utils/gn` to `utils/gn` as a prerequisite if that was preferred. Obviously it's easier for me to put it alongside gn in `llvm/utils/bazel`, but I thought since we were discussing this it might be a good time to consider whether that's actually the best place :-) And at some point I also mentioned that having "unsupported" somewhere in the path might help make the support status extremely clear, e.g. `utils/unsupported/[bazel|gn]`

"unsupported" is perhaps a bit overkill.

It'd probably be easier to start with llvm/utils for now to avoid involving the GN folks in the initial merge, and then the two sub-communities can join and move both to the root. Whatever works, though.

Tom Stellard via llvm-dev

unread,
Dec 4, 2020, 9:42:16 PM12/4/20
to Geoffrey Martin-Noble, LLVM Dev
On 12/3/20 4:27 PM, Geoffrey Martin-Noble wrote:
> Apologies for the delayed response here. I was out of the "office".
>
> Thanks for taking another look :-)
>
> I want to respond first to the process question of pitch vs RFC. My
> impression was that the pitch process should be used in the case that an
> RFC couldn't reach consensus. I asked a few times in the last thread
> (https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/m/uVlV3pMTBAAJ and
> https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/m/wF5mu-dpBAAJ)
> whether I should move this to a pitch, but feel like there wasn't a
> clear response in the context of Renato's support tiers RFC.
>
> It seems like Tom and Renato still disagree about whether I should move
> this to a pitch. I would appreciate some consensus on that point at
> least :-D I do see the appeal of a living document for this sort of
> thing, so definitely see the appeal there, but also it seems like the
> pitch process is a heavier-weight and more unusual one, so I was
> hesitant. My inclination is to continue this as an RFC unless we are
> unable to reach consensus on the issue as outlined in the pitch process
> description. It does feel like this is really not quite as big a
> decision as you seem to be suggesting. It's also an easily reversible
> one since there are no build dependencies and everything is contained.
>

I still think this should be a pitch. The original mailing list
discussion was controversial and that's when an RFC should be escalated
to a pitch according to: [1].

Thank you for responding to my technical concerns, and I agree that
working out most of those details may be better left for a patch review
discussion. But I think at least the presence of build information for
other projects and the sub-module alternative should be mentioned in the
pitch.

If there were only technical or support policy issues like these to
resolve then I don't think this would be controversial and require a pitch.

My main issue with this RFC, (which I tried to address at the end of my
previous mail), is the precedent this sets for what gets included in
tree. Essentially, we have a subset of our community that chose to go a
different direction from upstream, as always there are costs and
benefits with this decision. The question for the community is do we
want to help or encourage this in the future by removing some of the
costs of these decisions and allowing alternative implementations to
live in tree.

Maybe for build systems this is OK, and for other things this is not,
I don't know. But if we are going to be setting a precedent, to me, the
best way to do this is through the pitch process.

-Tom











[1]
https://github.com/llvm/llvm-www/blob/master/proposals/LP0001-LLVMDecisionMaking.md

> <https://docs.bazel.build/versions/master/repo/http.html#http_archive> which

> <https://github.com/plaidml/plaidml/blob/master/vendor/llvm/llvm.BUILD> (Intel)
> or this bazel_llvm <https://github.com/ChrisCummins/bazel_llvm> project

> that I found after someone contributed a doc fix. I believe in the last
> thread someone from Facebook mentioned that Bazel build files would also
> be relatively easily translatable to their internal Bazel-derived build
> system, Buck. Someone from Lyft also expressed interest in using a Bazel
> build configuration if it was in-tree. But I can't really speak to the
> motivations, road maps, etc. for any of these people, companies, or
> projects (if you're reading, please chime in ;-P).
>

_______________________________________________

Eric Christopher via llvm-dev

unread,
Dec 4, 2020, 9:52:25 PM12/4/20
to Tom Stellard, LLVM Dev
Hi Tom,

I disagree with this characterization of the proposal. I don't think anyone "chose" to do anything as it's integrating llvm with existing practice somewhere else. This could apply to any number of situations including, for example, rpm configuration files.

For the record, it's not even my proposal. I'm just looking at this with my (former) build systems maintainer and llvm hat on.
 
Maybe for build systems this is OK, and for other things this is not,
I don't know.  But if we are going to be setting a precedent, to me, the
best way to do this is through the pitch process.


But if you're going to insist then we need to go through the pitch process.

-eric

Mehdi AMINI via llvm-dev

unread,
Dec 4, 2020, 10:20:44 PM12/4/20
to Tom Stellard, LLVM Dev
On Fri, Dec 4, 2020 at 6:42 PM Tom Stellard via llvm-dev <llvm...@lists.llvm.org> wrote:
On 12/3/20 4:27 PM, Geoffrey Martin-Noble wrote:
> Apologies for the delayed response here. I was out of the "office".
>
> Thanks for taking another look :-)
>
> I want to respond first to the process question of pitch vs RFC. My
> impression was that the pitch process should be used in the case that an
> RFC couldn't reach consensus. I asked a few times in the last thread
> (https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/m/uVlV3pMTBAAJ and
> https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/m/wF5mu-dpBAAJ)
> whether I should move this to a pitch, but feel like there wasn't a
> clear response in the context of Renato's support tiers RFC.
>
> It seems like Tom and Renato still disagree about whether I should move
> this to a pitch. I would appreciate some consensus on that point at
> least :-D I do see the appeal of a living document for this sort of
> thing, so definitely see the appeal there, but also it seems like the
> pitch process is a heavier-weight and more unusual one, so I was
> hesitant. My inclination is to continue this as an RFC unless we are
> unable to reach consensus on the issue as outlined in the pitch process
> description. It does feel like this is really not quite as big a
> decision as you seem to be suggesting. It's also an easily reversible
> one since there are no build dependencies and everything is contained.
>

I still think this should be a pitch.  The original mailing list
discussion was controversial and that's when an RFC should be escalated
to a pitch according to: [1].

You may have missed it, but in the meantime there has been another RFC clarifying our policy though: https://llvm.org/docs/SupportPolicy.html
It seems fair to me to revisit this RFC as is in light of the policy change.

I'd actually like to request that the objections are reiterated and positioned in terms of the policy before we escalate this.
 

Thank you for responding to my technical concerns, and I agree that
working out most of those details may be better left for a patch review
discussion.  But I think at least the presence of build information for
other projects and the sub-module alternative should be mentioned in the
pitch.

If there were only technical or support policy issues like these to
resolve then I don't think this would be controversial and require a pitch.

My main issue with this RFC, (which I tried to address at the end of my
previous mail), is the precedent this sets for what gets included in
tree.  Essentially, we have a subset of our community that chose to go a
different direction from upstream, as always there are costs and
benefits with this decision.  The question for the community is do we
want to help or encourage this in the future by removing some of the
costs of these decisions and allowing alternative implementations to
live in tree.

Maybe for build systems this is OK, and for other things this is not,
I don't know.  But if we are going to be setting a precedent, to me, the
best way to do this is through the pitch process.

Why are you considering this "setting a precedent" while there is already GN in tree?

-- 
Mehdi

Tom Stellard via llvm-dev

unread,
Dec 4, 2020, 11:07:56 PM12/4/20
to Mehdi AMINI, LLVM Dev

I don't think the questions about whether or not this should be included
in the project are answered by this new policy. To me the part about
how the bazel build files were going to be supported and what
responsibility the community had for maintaining them was always very clear.

> I'd actually like to request that the objections are reiterated and
> positioned in terms of the policy before we escalate this.
>

I don't think it's really fair to ask people to re-object to the
proposal. In my opinion, one of the problems with RFCs in the past is
that they turn into an endurance test, because there is no process for
making a decision. Either the proposer gets tired of asking and gives
up or the objectors get tired of objecting and give up. We have a
decision process now with the pitch process, and I think we should use it.

>
> Thank you for responding to my technical concerns, and I agree that
> working out most of those details may be better left for a patch review
> discussion.  But I think at least the presence of build information for
> other projects and the sub-module alternative should be mentioned in
> the
> pitch.
>
> If there were only technical or support policy issues like these to
> resolve then I don't think this would be controversial and require a
> pitch.
>
> My main issue with this RFC, (which I tried to address at the end of my
> previous mail), is the precedent this sets for what gets included in
> tree.  Essentially, we have a subset of our community that chose to
> go a
> different direction from upstream, as always there are costs and
> benefits with this decision.  The question for the community is do we
> want to help or encourage this in the future by removing some of the
> costs of these decisions and allowing alternative implementations to
> live in tree.
>
> Maybe for build systems this is OK, and for other things this is not,
> I don't know.  But if we are going to be setting a precedent, to me,
> the
> best way to do this is through the pitch process.
>
>
> Why are you considering this "setting a precedent" while there is
> already GN in tree?
>

You are right we are not really setting a precedent here, because GN is
already in tree. However, I don't think we should now just allow any
build system to be added to the tree just because GN is there. We need
to have some kind of process and criteria for deciding what gets added
and what doesn't. I think a pitch will help accomplish this.

I'll be honest, I don't really understand why there is so much push back
on turning this into a pitch. Is it really that much extra work?

-Tom

> --
> Mehdi
>
>
>
>
> -Tom
>
>
>
>
>
>
>
>
>
>
>
>
>
> [1]
> https://github.com/llvm/llvm-www/blob/master/proposals/LP0001-LLVMDecisionMaking.md
>
> > On Mon, Nov 16, 2020 at 9:41 PM Tom Stellard <tste...@redhat.com
> <mailto:tste...@redhat.com>

> > <mailto:reng...@gmail.com <mailto:reng...@gmail.com>>> wrote:
> >
> >     Hi Geoffrey,
> >
> >     Thanks for the re-submission.
> >
> >     I have some comments below that may sound negative, but they're
> >     probably just a reflection of my own ignorance. I want to
> make sure
> >     the submission is clear, so it can be accepted on its own right.
> >
> >     On Tue, 17 Nov 2020 at 03:02, Geoffrey Martin-Noble via llvm-dev
> >     <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>

> <mailto:llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>>>

> llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Mehdi AMINI via llvm-dev

unread,
Dec 4, 2020, 11:17:44 PM12/4/20
to Tom Stellard, LLVM Dev
I'll quote the policy:

> Section: "What is covered"
> The peripheral tier is composed of:
> Experimental targets and options that haven’t been enable by default yet.
> Main repository projects that don’t get released or regularly tested.
> Legacy tools and scripts that aren’t used in upstream validation.
> Alternative build systems (ex. GN, Bazel) and related infrastructure.

The intent of the policy is to cover exactly this proposal.
 

 
To me the part about
how the bazel build files were going to be supported and what
responsibility the community had for maintaining them was always very clear.

> I'd actually like to request that the objections are reiterated and
> positioned in terms of the policy before we escalate this.
>

I don't think it's really fair to ask people to re-object to the
proposal. 

Why?
The objections were mostly answered and have been addressed in the policy. I don't quite get what you would put in a "pitch" while the informations are outdated by the policy.
On the contrary it seems not only fair to me, but necessary.

 
In my opinion, one of the problems with RFCs in the past is
that they turn into an endurance test, because there is no process for
making a decision.  Either the proposer gets tired of asking and gives
up or the objectors get tired of objecting and give up.  We have a
decision process now with the pitch process, and I think we should use it

We have to use it when we can't do otherwise. And again, I disagree that this is a case without having objection formulated in light of the policy.

Mehdi AMINI via llvm-dev

unread,
Dec 4, 2020, 11:32:32 PM12/4/20
to Tom Stellard, LLVM Dev
Another spin to it: the point of working on the policy and putting it in place was also to help make sure that such proposals aren't automatically controversial to the point where we can't resolve them. If the policy does not help us here, that's quite a failure IMO.

Tom Stellard via llvm-dev

unread,
Dec 4, 2020, 11:56:43 PM12/4/20
to Mehdi AMINI, LLVM Dev
On 12/4/20 8:17 PM, Mehdi AMINI wrote:
>
>
> On Fri, Dec 4, 2020 at 8:07 PM Tom Stellard <tste...@redhat.com
> <mailto:tste...@redhat.com>> wrote:
>
> On 12/4/20 7:19 PM, Mehdi AMINI wrote:
> >
> >
> > On Fri, Dec 4, 2020 at 6:42 PM Tom Stellard via llvm-dev
> > <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>
> > *Alternative build systems (ex. GN, Bazel) and related infrastructure.*

>
> The intent of the policy is to cover exactly this proposal.
>

My understanding of the policy is that these categories of things still
need to be approved in order to be added to the tree. Am I correct, or
does this policy allow anyone to add an alternative build system as long
as they can satisfy the support requirements.

> To me the part about
> how the bazel build files were going to be supported and what
> responsibility the community had for maintaining them was always
> very clear.
>
> > I'd actually like to request that the objections are reiterated and
> > positioned in terms of the policy before we escalate this.
> >
>
> I don't think it's really fair to ask people to re-object to the
> proposal.
>
>
> Why?
> The objections were mostly answered and have been addressed in the
> policy. I don't quite get what you would put in a "pitch" while the
> informations are outdated by the policy.
> On the contrary it seems not only fair to me, but necessary.

I don't really agree that all the objections were addressed. Maybe we
should directly reach out to people from the original thread and ask them?

I'm not really a fan of having another build system in tree, but I also
don't want to keep devoting a lot of time to arguing about it. I was
hoping that with the pitch process, we could avoid the kind of back and
forth arguing on the list that typically make these RFCs so tiring.

I still don't quite understand why there is so much push back against
pitches, but I think everyone knows my perspective now, so I'm going to
step back and let other people work out what the next steps should be.

-Tom

> <mailto:llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org

https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Stefan Teleman via llvm-dev

unread,
Dec 5, 2020, 12:06:15 AM12/5/20
to LLVM Dev
On Fri, Dec 4, 2020 at 11:32 PM Mehdi AMINI via llvm-dev
<llvm...@lists.llvm.org> wrote:

> Another spin to it: the point of working on the policy and putting it in place was also to help make sure that such proposals aren't automatically controversial to the point where we can't resolve them. If the policy does not help us here, that's quite a failure IMO.

This proposal isn't controversial because of the policy.

As a matter of historical record, this new policy was shoehorned into
existence ex post facto, after the Bazel build system decision had
already been made, and because some people - myself included -
objected to the proposal. The policy doesn't address the potentially
infinite proliferation of build systems and build system files in
LLVM. Quite the opposite.

And since you asked: my objections remain the same. In my opinion,
Bazel build system infrastructure files do not belong in the LLVM tree
anymore than GN, or autoconf, or rpm specs, or Solaris pkg specs do.

Folks who want to use Bazel to build LLVM can accomplish their goal by
creating an overlay Git repo containing and providing the Bazel build
files from there. That approach would simplify life for everyone.
There would be no need for this tiered support policy, and there's
nothing controversial about having an overlay Git repo independent of
LLVM. Anyone can create their own overlay build system repo containing
build files for their favorite build system. It doesn't require LLVM
consent.

--
Stefan Teleman
stefan....@gmail.com


_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org

https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Mehdi AMINI via llvm-dev

unread,
Dec 5, 2020, 12:23:07 AM12/5/20
to Stefan Teleman, LLVM Dev
On Fri, Dec 4, 2020 at 9:06 PM Stefan Teleman via llvm-dev <llvm...@lists.llvm.org> wrote:
On Fri, Dec 4, 2020 at 11:32 PM Mehdi AMINI via llvm-dev
<llvm...@lists.llvm.org> wrote:

> Another spin to it: the point of working on the policy and putting it in place was also to help make sure that such proposals aren't automatically controversial to the point where we can't resolve them. If the policy does not help us here, that's quite a failure IMO.

This proposal isn't controversial because of the policy.

As a matter of historical record, this new policy was shoehorned into
existence ex post facto, after the Bazel build system decision had
already been made, and because some people - myself included -
objected to the proposal. The policy doesn't address the potentially
infinite proliferation of build systems and build system files in
LLVM. Quite the opposite.

And since you asked: my objections remain the same.  In my opinion,
Bazel build system infrastructure files do not belong in the LLVM tree
anymore than GN, or autoconf, or rpm specs, or Solaris pkg specs do.

So you oppose the policy itself, not this particular proposal alone? That's fine but that's an important clarification because there is nothing this proposal can do to address it, and the point of the policy is to be able to consider such proposal without blocking them with such an objection.

Mehdi AMINI via llvm-dev

unread,
Dec 5, 2020, 12:29:04 AM12/5/20
to Tom Stellard, LLVM Dev
I agree with you, but that does not make it a justification for a pitch automatically.
The policy gives us a framework to discuss and avoids to rehash the same set of arguments over and over:  for example we don't object to a specific proposal because we don't agree with the policy, but because of the specifics of a particular proposal.
Similarly, an RFC or a pitch shouldn't have to re-evaluate what has been codified as OK in a policy, otherwise what is the point of codifying it in the first place if everything is always revisited?


>     To me the part about
>     how the bazel build files were going to be supported and what
>     responsibility the community had for maintaining them was always
>     very clear.
>
>      > I'd actually like to request that the objections are reiterated and
>      > positioned in terms of the policy before we escalate this.
>      >
>
>     I don't think it's really fair to ask people to re-object to the
>     proposal.
>
>
> Why?
> The objections were mostly answered and have been addressed in the
> policy. I don't quite get what you would put in a "pitch" while the
> informations are outdated by the policy.
> On the contrary it seems not only fair to me, but necessary.

I don't really agree that all the objections were addressed.  Maybe we
should directly reach out to people from the original thread and ask them?

Seems like we agree in the end: we need the objections to be restated :)
 

I'm not really a fan of having another build system in tree, but I also
don't want to keep devoting a lot of time to arguing about it.  I was
hoping that with the pitch process, we could avoid the kind of back and
forth arguing on the list that typically make these RFCs so tiring.

I still don't quite understand why there is so much push back against
pitches, but I think everyone knows my perspective now, so I'm going to
step back and let other people work out what the next steps should be.

Can only speak for myself: I believe pitches should be more of a "last resort" than "the normal way of driving any proposal". I object to what I see using too easily a "pitch" as a way to "work around discussions".

-- 
Mehdi

Stefan Teleman via llvm-dev

unread,
Dec 5, 2020, 12:35:25 AM12/5/20
to LLVM Dev
On Sat, Dec 5, 2020 at 12:23 AM Mehdi AMINI <joke...@gmail.com> wrote:
>
> On Fri, Dec 4, 2020 at 9:06 PM Stefan Teleman via llvm-dev <llvm...@lists.llvm.org> wrote:
>>
>> On Fri, Dec 4, 2020 at 11:32 PM Mehdi AMINI via llvm-dev
>> <llvm...@lists.llvm.org> wrote:
>>
>> > Another spin to it: the point of working on the policy and putting it in place was also to help make sure that such proposals aren't automatically controversial to the point where we can't resolve them. If the policy does not help us here, that's quite a failure IMO.
>>
>> This proposal isn't controversial because of the policy.
>>
>> As a matter of historical record, this new policy was shoehorned into
>> existence ex post facto, after the Bazel build system decision had
>> already been made, and because some people - myself included -
>> objected to the proposal. The policy doesn't address the potentially
>> infinite proliferation of build systems and build system files in
>> LLVM. Quite the opposite.
>>
>> And since you asked: my objections remain the same. In my opinion,
>> Bazel build system infrastructure files do not belong in the LLVM tree
>> anymore than GN, or autoconf, or rpm specs, or Solaris pkg specs do.
>
>
> So you oppose the policy itself, not this particular proposal alone? That's fine but that's an important clarification because there is nothing this proposal can do to address it, and the point of the policy is to be able to consider such proposal without blocking them with such an objection.

No and No.

Q: Do I oppose the policy?
A: No, I don't. As I have already stated, the policy was created after
the fact. I am in opposition to the fact. The policy is secondary, and
irrelevant, because its only purpose is to provide cover for the
existing fact. If the fact didn't exist, the policy wouldn't be
necessary.

Q: Do I not oppose this particular proposal?
(Warning: bumpy road ahead: double-negation.)
A: No, I do not not oppose this particular proposal.
Reduction: Yes, I object to this proposal, just like I objected a
month and a half ago (or so).

Eric Christopher via llvm-dev

unread,
Dec 5, 2020, 12:40:41 AM12/5/20
to Stefan Teleman, LLVM Dev
On Sat, Dec 5, 2020 at 12:35 AM Stefan Teleman via llvm-dev <llvm...@lists.llvm.org> wrote:
On Sat, Dec 5, 2020 at 12:23 AM Mehdi AMINI <joke...@gmail.com> wrote:
>
> On Fri, Dec 4, 2020 at 9:06 PM Stefan Teleman via llvm-dev <llvm...@lists.llvm.org> wrote:
>>
>> On Fri, Dec 4, 2020 at 11:32 PM Mehdi AMINI via llvm-dev
>> <llvm...@lists.llvm.org> wrote:
>>
>> > Another spin to it: the point of working on the policy and putting it in place was also to help make sure that such proposals aren't automatically controversial to the point where we can't resolve them. If the policy does not help us here, that's quite a failure IMO.
>>
>> This proposal isn't controversial because of the policy.
>>
>> As a matter of historical record, this new policy was shoehorned into
>> existence ex post facto, after the Bazel build system decision had
>> already been made, and because some people - myself included -
>> objected to the proposal. The policy doesn't address the potentially
>> infinite proliferation of build systems and build system files in
>> LLVM. Quite the opposite.
>>
>> And since you asked: my objections remain the same.  In my opinion,
>> Bazel build system infrastructure files do not belong in the LLVM tree
>> anymore than GN, or autoconf, or rpm specs, or Solaris pkg specs do.
>
>
> So you oppose the policy itself, not this particular proposal alone? That's fine but that's an important clarification because there is nothing this proposal can do to address it, and the point of the policy is to be able to consider such proposal without blocking them with such an objection.

No and No.

Q: Do I oppose the policy?
A: No, I don't. As I have already stated, the policy was created after
the fact. I am in opposition to the fact. The policy is secondary, and
irrelevant, because its only purpose is to provide cover for the
existing fact. If the fact didn't exist, the policy wouldn't be
necessary.


I'm sorry, but this is incorrect in every word. The policy encoded existing practice over the last decade plus and is as we have been implementing all along. If that doesn't match your experiences as a newer developer I'm quite sorry, but is the case.

Thanks.

-eric 

Mehdi AMINI via llvm-dev

unread,
Dec 5, 2020, 12:42:43 AM12/5/20
to Stefan Teleman, LLVM Dev
On Fri, Dec 4, 2020 at 9:35 PM Stefan Teleman via llvm-dev <llvm...@lists.llvm.org> wrote:
On Sat, Dec 5, 2020 at 12:23 AM Mehdi AMINI <joke...@gmail.com> wrote:
>
> On Fri, Dec 4, 2020 at 9:06 PM Stefan Teleman via llvm-dev <llvm...@lists.llvm.org> wrote:
>>
>> On Fri, Dec 4, 2020 at 11:32 PM Mehdi AMINI via llvm-dev
>> <llvm...@lists.llvm.org> wrote:
>>
>> > Another spin to it: the point of working on the policy and putting it in place was also to help make sure that such proposals aren't automatically controversial to the point where we can't resolve them. If the policy does not help us here, that's quite a failure IMO.
>>
>> This proposal isn't controversial because of the policy.
>>
>> As a matter of historical record, this new policy was shoehorned into
>> existence ex post facto, after the Bazel build system decision had
>> already been made, and because some people - myself included -
>> objected to the proposal. The policy doesn't address the potentially
>> infinite proliferation of build systems and build system files in
>> LLVM. Quite the opposite.
>>
>> And since you asked: my objections remain the same.  In my opinion,
>> Bazel build system infrastructure files do not belong in the LLVM tree
>> anymore than GN, or autoconf, or rpm specs, or Solaris pkg specs do.
>
>
> So you oppose the policy itself, not this particular proposal alone? That's fine but that's an important clarification because there is nothing this proposal can do to address it, and the point of the policy is to be able to consider such proposal without blocking them with such an objection.

No and No.

Q: Do I oppose the policy?
A: No, I don't.

Sorry I don't quite get what you mean here and it is quite confusing to me: if you don't oppose the policy, that means you don't have an issue with it?
 
As I have already stated, the policy was created after
the fact. I am in opposition to the fact. The policy is secondary, and
irrelevant, because its only purpose is to provide cover for the
existing fact. If the fact didn't exist, the policy wouldn't be
necessary.

I don't quite get how the policy is irrelevant.

 

Q: Do I not oppose this particular proposal?
(Warning: bumpy road ahead: double-negation.)
A: No, I do not not oppose this particular proposal.
Reduction: Yes, I object to this proposal, just like I objected a
month and a half ago (or so).

Right, but you're also objecting to GN being in-tree if I understand correctly (I'm not sure I understand you correctly though, since you just wrote above you don't oppose the policy).

-- 
Mehdi

Stefan Teleman via llvm-dev

unread,
Dec 5, 2020, 12:45:27 AM12/5/20
to LLVM Dev
On Sat, Dec 5, 2020 at 12:40 AM Eric Christopher <echr...@gmail.com> wrote:
>
> On Sat, Dec 5, 2020 at 12:35 AM Stefan Teleman via llvm-dev <llvm...@lists.llvm.org> wrote:

>> Q: Do I oppose the policy?
>> A: No, I don't. As I have already stated, the policy was created after
>> the fact. I am in opposition to the fact. The policy is secondary, and
>> irrelevant, because its only purpose is to provide cover for the
>> existing fact. If the fact didn't exist, the policy wouldn't be
>> necessary.
>>
>
> I'm sorry, but this is incorrect in every word. The policy encoded existing practice over the last decade plus and is as we have been implementing all along. If that doesn't match your experiences as a newer developer I'm quite sorry, but is the case.

By "last decade" you probably mean the sudden appearance of the GN
build files. I wouldn't call it "last decade". Perhaps "last year or
so" would be more accurate.

Please don't pull rank. It's tacky and uncalled for.

Thanks.

Eric Christopher via llvm-dev

unread,
Dec 5, 2020, 12:48:39 AM12/5/20
to Stefan Teleman, LLVM Dev
On Sat, Dec 5, 2020 at 12:45 AM Stefan Teleman via llvm-dev <llvm...@lists.llvm.org> wrote:
On Sat, Dec 5, 2020 at 12:40 AM Eric Christopher <echr...@gmail.com> wrote:
>
> On Sat, Dec 5, 2020 at 12:35 AM Stefan Teleman via llvm-dev <llvm...@lists.llvm.org> wrote:

>> Q: Do I oppose the policy?
>> A: No, I don't. As I have already stated, the policy was created after
>> the fact. I am in opposition to the fact. The policy is secondary, and
>> irrelevant, because its only purpose is to provide cover for the
>> existing fact. If the fact didn't exist, the policy wouldn't be
>> necessary.
>>
>
> I'm sorry, but this is incorrect in every word. The policy encoded existing practice over the last decade plus and is as we have been implementing all along. If that doesn't match your experiences as a newer developer I'm quite sorry, but is the case.

By "last decade" you probably mean the sudden appearance of the GN
build files. I wouldn't call it "last decade". Perhaps "last year or
so" would be more accurate.


No. I meant every word that I said. The policy encoded existing practice and exactly how we've handled things for years. I'm sorry if this hasn't matched your experiences, as I said, but there's nothing new or radical with what we wrote down. It's what we've intended and how we've meant to act.
 
Please don't pull rank. It's tacky and uncalled for.

Avoid the personal commentary, I'm giving you context that you may not have.

Thanks.

-eric

Stefan Teleman via llvm-dev

unread,
Dec 5, 2020, 1:01:37 AM12/5/20
to Mehdi AMINI, LLVM Dev
On Sat, Dec 5, 2020 at 12:42 AM Mehdi AMINI <joke...@gmail.com> wrote:

> Sorry I don't quite get what you mean here and it is quite confusing to me: if you don't oppose the policy, that means you don't have an issue with it?

I think I've already explained it. I don't have an issue with the
policy because the policy does not address my main concern.
My main concern - already stated today, and several weeks ago - is the
open-ended proliferation of build system files.

> I don't quite get how the policy is irrelevant.

It doesn't address the concern I expressed above. It's the same
concern I raised back on October.

> Right, but you're also objecting to GN being in-tree if I understand correctly (I'm not sure I understand you correctly though, since you just wrote above you don't oppose the policy).

I do not agree with the GN files being in-tree - for the same reasons
I object to the Bazel files - but, unlike the Bazel files, GN is an
accomplished fact at this point. Contrary to other statements made
here, the GN files appeared in the LLVM tree relatively recently.

At any rate, I am perfectly aware that the Bazel files will end up in
the LLVM tree.

You asked for objections to be re-stated, I re-stated mine.

Renato Golin via llvm-dev

unread,
Dec 5, 2020, 12:34:50 PM12/5/20
to tste...@redhat.com, LLVM Dev
On Sat, 5 Dec 2020 at 04:56, Tom Stellard via llvm-dev <llvm...@lists.llvm.org> wrote:
My understanding of the policy is that these categories of things still
need to be approved in order to be added to the tree.  Am I correct, or
does this policy allow anyone to add an alternative build system as long
as they can satisfy the support requirements.

That is my understanding as well. I don't think any policy in LLVM gives people carte blanche to do anything without consensus.

They merely outline the requirements to be accepted, so that we don't need to repeat them on every RFC.

I'm not really a fan of having another build system in tree, but I also
don't want to keep devoting a lot of time to arguing about it.  I was
hoping that with the pitch process, we could avoid the kind of back and
forth arguing on the list that typically make these RFCs so tiring.

Indeed. We seem to be getting the same kind of questions and answers from the first iteration.

I believe having a pitch document would be "faster" and generate less conflict than continuing this RFC.

Pitch versus RFC should be orthogonal to the (recently added and still immature) support policy. 

I see pitches as a way to solve conflicts, not add bureaucracy.

cheers,
--renato

Renato Golin via llvm-dev

unread,
Dec 5, 2020, 1:15:41 PM12/5/20
to Eric Christopher, LLVM Dev
On Sat, 5 Dec 2020 at 05:48, Eric Christopher via llvm-dev <llvm...@lists.llvm.org> wrote:
No. I meant every word that I said. The policy encoded existing practice and exactly how we've handled things for years. I'm sorry if this hasn't matched your experiences, as I said, but there's nothing new or radical with what we wrote down. It's what we've intended and how we've meant to act.

Precisely.

I'm not taking personally the statement that "[the policy's] only purpose is to provide cover for the existing fact". I have no reason to provide cover for Bazel, Geoffrey or Google. I didn't mean to create precedent for anything and just wanted to make sure we discuss the technical details with the background of how we decide things covered in a policy that would only describe what we've done in the past.

I also don't think the inclusion of GN is prior-art. It had a lot less scrutiny than the current discussion and it has been largely ignored (because nothing wrong happened so far). There are lots of little things like that in LLVM that go unnoticed, it's really hard to control such a large project without adding unreasonable constraints to the development process.

It's exactly because this discussion is again moving into personal remarks and making use of "facts" and policies that I'm sure this won't go anywhere, again. And this is why I support Tom's idea to turn this into a pitch: there are no personal opinions on the document, just facts and solutions to problems.

cheers,
--renato

Chris Lattner via llvm-dev

unread,
Dec 5, 2020, 1:32:07 PM12/5/20
to Mehdi AMINI, LLVM Dev


On Dec 4, 2020, at 9:28 PM, Mehdi AMINI via llvm-dev <llvm...@lists.llvm.org> wrote:

I'm not really a fan of having another build system in tree, but I also 
don't want to keep devoting a lot of time to arguing about it.  I was 
hoping that with the pitch process, we could avoid the kind of back and 
forth arguing on the list that typically make these RFCs so tiring.

I still don't quite understand why there is so much push back against 
pitches, but I think everyone knows my perspective now, so I'm going to 
step back and let other people work out what the next steps should be.

Can only speak for myself: I believe pitches should be more of a "last resort" than "the normal way of driving any proposal". I object to what I see using too easily a "pitch" as a way to "work around discussions”.

Right, it is an intentionally fairly heavy weight process, so it should be used sparingly.  That doesn’t mean it is a “last resort” thing though, we can use it when we think it will be valuable.

Random nit: please refer to it as the “LLVM Proposal Process”, a pitch is just one stage of that process.

-Chris

Mehdi AMINI via llvm-dev

unread,
Dec 5, 2020, 11:17:43 PM12/5/20
to Stefan Teleman, LLVM Dev
On Fri, Dec 4, 2020 at 10:01 PM Stefan Teleman <stefan....@gmail.com> wrote:
On Sat, Dec 5, 2020 at 12:42 AM Mehdi AMINI <joke...@gmail.com> wrote:

> Sorry I don't quite get what you mean here and it is quite confusing to me: if you don't oppose the policy, that means you don't have an issue with it?

I think I've already explained it. I don't have an issue with the
policy because the policy does not address my main concern.
My main concern - already stated today, and several weeks ago - is the
open-ended proliferation of build system files. 

> I don't quite get how the policy is irrelevant.

It doesn't address the concern I expressed above. It's the same
concern I raised back on October.

Maybe we're not reading the same thing, it says:

"The peripheral tier is composed of: [...] Alternative build systems (ex. GN, Bazel) and related infrastructure.".

Isn't this addressing your general objection to a "proliferation of build system files"?
 

> Right, but you're also objecting to GN being in-tree if I understand correctly (I'm not sure I understand you correctly though, since you just wrote above you don't oppose the policy).

I do not agree with the GN files being in-tree - for the same reasons
I object to the Bazel files - but, unlike the Bazel files,  GN is an
accomplished fact at this point. Contrary to other statements made
here, the GN files appeared in the LLVM tree relatively recently.

At any rate, I am perfectly aware that the Bazel files will end up in
the LLVM tree.

You asked for objections to be re-stated, I re-stated mine.

Right, thanks for that.
I noted that you object about the principle of adding build system files by itself (which is something mentioned in the policy as stated above). I haven't noted though a particular concern of your that would be specific about Bazel or anything specific that is proposed here.

Best,

-- 
Mehdi

Mehdi AMINI via llvm-dev

unread,
Dec 5, 2020, 11:38:52 PM12/5/20
to Renato Golin, LLVM Dev
On Sat, Dec 5, 2020 at 10:15 AM Renato Golin via llvm-dev <llvm...@lists.llvm.org> wrote:
On Sat, 5 Dec 2020 at 05:48, Eric Christopher via llvm-dev <llvm...@lists.llvm.org> wrote:
No. I meant every word that I said. The policy encoded existing practice and exactly how we've handled things for years. I'm sorry if this hasn't matched your experiences, as I said, but there's nothing new or radical with what we wrote down. It's what we've intended and how we've meant to act.

Precisely.

I'm not taking personally the statement that "[the policy's] only purpose is to provide cover for the existing fact". I have no reason to provide cover for Bazel, Geoffrey or Google. I didn't mean to create precedent for anything and just wanted to make sure we discuss the technical details with the background of how we decide things covered in a policy that would only describe what we've done in the past.

I also don't think the inclusion of GN is prior-art. It had a lot less scrutiny than the current discussion and it has been largely ignored (because nothing wrong happened so far). There are lots of little things like that in LLVM that go unnoticed, it's really hard to control such a large project without adding unreasonable constraints to the development process.

It isn't clear to me what makes you say that? You may not have been involved with it and you may haven't been paying attention at the time, but it seems unfair to claim that it didn't have scrutiny or it went in without the usual proper consideration.
In particular it has been discussed on llvm-dev@ like any other proposal, and the thread was pretty long: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html ; it also went further with a lightning talk **and** a round-table during a llvm dev meeting.

 
It's exactly because this discussion is again moving into personal remarks and making use of "facts" and policies that I'm sure this won't go anywhere, again. And this is why I support Tom's idea to turn this into a pitch: there are no personal opinions on the document, just facts and solutions to problems.

I'll repeat myself but: escalating an RFC into a  “LLVM Proposal Process” requires being able to "describe the controversy" and summarize both sides of the discussion. I don't see how this is possible without having the objections being restated.
So far Chris withdrawn his objection in light of the policy you drove: "Since this is being added within the bounds of a now-existing policy, I will withdraw my objections".
Stefan reiterated his objection, but I read it as in bound for the policy rather than really about this proposal (I may be wrong, that's just how I understand it).

Another issue I see with escalating, is that while the “LLVM Proposal Process” seems like a way to unblock deadlocks, it isn't clear to me that it is the best way to find tradeoff and compromise that can be reached through discussions.
For example there are very good technical questions raised by Tom in the bullet points in the second part of this email: http://lists.llvm.org/pipermail/llvm-dev/2020-November/146671.html ; I'm afraid that these wouldn't be addressed the same way if we just moved on with a more formal decision process. I don't understand why we shouldn't make a genuine effort to address the practical aspects here?
-- 
Mehdi


Stefan Teleman via llvm-dev

unread,
Dec 5, 2020, 11:46:39 PM12/5/20
to LLVM Dev
On Sat, Dec 5, 2020 at 11:17 PM Mehdi AMINI <joke...@gmail.com> wrote:

> Right, thanks for that.
> I noted that you object about the principle of adding build system files by itself (which is something mentioned in the policy as stated above). I haven't noted though a particular concern of your that would be specific about Bazel or anything specific that is proposed here.

Yes, that is correct. We have a disagreement on principle, not a
disagreement about implementation details.

The consensus seems to be that these infrastructure build files can
reside in the LLVM tree because they (a) aren't harmful, (b) there is
a policy in place that constrains the community's expectations about
levels of involvement and support and, overall, this infrastructure
overhead will manage itself safely and sanely according to the policy.

That seems true in theory, based on the current policy, and assuming
everything goes according to plan.

In real life, things sometimes don't go according to plan. What I mean
by that is: there will be (inevitably) bitrot. Meaning, some of these
build infrastructure files will become orphans, with no clear
maintainer. This happens even with LLVM components that are classified
as Tier 1 - for example LLVM backends. I remember there was a
discussion here, somewhat recently, about one of the LLVM backends
becoming unmaintained, and therefore somewhat of an orphan (I can't
remember exactly which backend right now).

When this happens, it automatically becomes an overhead on the active
community. Someone has to spend time tracking down the last known
owner, and inquire about the state of the component: Is it still
maintained? Is it still of interest? If <person-X> can't be the
official maintainer any longer, can they recommend an alternate
<person-Y> that can take over? Should we keep it in-tree? Should we
get rid of it? etc etc etc. Then comes the ensuing discussion with the
community about what to do with the orphan.

To make it short: by now, all of this has become 100% overhead. It has
very little to do with LLVM (or clang or MLIR or anything)
development.

So my question (and the basis for my opposing view of not keeping
infrastructure build files in-tree): Why incur the risk of
(inevitable) overhead?

------

Renato Golin via llvm-dev

unread,
Dec 6, 2020, 7:08:08 AM12/6/20
to Mehdi AMINI, LLVM Dev
On Sun, 6 Dec 2020 at 04:38, Mehdi AMINI <joke...@gmail.com> wrote:
It isn't clear to me what makes you say that? You may not have been involved with it and you may haven't been paying attention at the time, but it seems unfair to claim that it didn't have scrutiny or it went in without the usual proper consideration.
In particular it has been discussed on llvm-dev@ like any other proposal, and the thread was pretty long: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html ; it also went further with a lightning talk **and** a round-table during a llvm dev meeting.

Sorry, scrutiny was the wrong word. I meant "trouble". This proposal seems to be having a lot of trouble that GN should have had too. The biggest push back is about adding new build systems, not Bazel versus GN versus CMake.

There seems to be a conflict here about adding a secondary build system. The first could be always thought of as an exception, but the second looks very much like a pattern. The way I see it, from one side there's people worried about maintenance and proliferation of code that is not directly related to the LLVM project (like build systems, editor files, etc) and from the other side, there's people saying this has been happening for a long time.

I tried to solve that by starting the support policy, but not with the intent to validate the inclusion of GN/Bazel, just to help the discussion move to a consensus. I regret having written GN and Bazel by name, which only now I realise they could be used as leverage for one side of the discussion. It was not my intention, and I don't think we should ignore the issues just because GN has been included already, either.

My support for moving this to a document (not necessarily a proposal) is because for most of the original discussion around Bazel, throughout the discussion about the support policy and now the retake on Bazel's inclusions, Tom's points haven't been addressed completely. There seems to be more discussion around semantics, history and precedence than the actual technical details. I'm guilty of that, too, while trying to solve the conflict, and I apologise if the support policy has created more confusion than it solved.

I think laying out the issues in a document and discussing the technical aspects over it would make things easier, not harder. If the support policy needs to be amended to clarify that, so be it. We need to document what happens and what we want to happen, not fix some version of the past as a golden standard for the future.

But as I always say: whatever works. If you want to continue discussing in this thread, by all means, do go on.

cheers,
--renato

Chris Tetreault via llvm-dev

unread,
Dec 7, 2020, 12:24:48 PM12/7/20
to Geoffrey Martin-Noble, LLVM Dev

Just to be clear, I’m still not in love with this plan. However, it’s being done in accordance with the new policy on this sort of thing, and I’m going to have faith that the policy has teeth if it becomes any sort of issue.

 

Thanks,

   Christopher Tetreault

 

From: Geoffrey Martin-Noble <gc...@google.com>
Sent: Thursday, December 3, 2020 4:27 PM
To: LLVM Dev <llvm...@lists.llvm.org>
Cc: tste...@redhat.com; Renato Golin <reng...@gmail.com>; Chris Tetreault <ctet...@quicinc.com>
Subject: [EXT] Re: [llvm-dev] RFC: Contributing Bazel BUILD files in the "peripheral" support tier

 

Apologies for the delayed response here. I was out of the "office".

 

Thanks for taking another look :-)

 

I want to respond first to the process question of pitch vs RFC. My impression was that the pitch process should be used in the case that an RFC couldn't reach consensus. I asked a few times in the last thread (https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/m/uVlV3pMTBAAJ and https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/m/wF5mu-dpBAAJ) whether I should move this to a pitch, but feel like there wasn't a clear response in the context of Renato's support tiers RFC.

 

It seems like Tom and Renato still disagree about whether I should move this to a pitch. I would appreciate some consensus on that point at least :-D I do see the appeal of a living document for this sort of thing, so definitely see the appeal there, but also it seems like the pitch process is a heavier-weight and more unusual one, so I was hesitant. My inclination is to continue this as an RFC unless we are unable to reach consensus on the issue as outlined in the pitch process description. It does feel like this is really not quite as big a decision as you seem to be suggesting. It's also an easily reversible one since there are no build dependencies and everything is contained.

 

On Mon, Nov 16, 2020 at 9:41 PM Tom Stellard <tste...@redhat.com> wrote:

> This should have approximately the same impact on the community as the
> current GN build in `llvm/utils/gn` does today. That is, it should not
> affect anyone who doesn't care.
>

I want to push back on this a little bit, because having the code in
tree does impact everyone, even people who don't care about it.  It
increases disk usage, commit traffic, checkout times, bugzilla / issue
traffic, and CI builds to name a few things.  There are costs to having
this in tree, the question (as always) is do the benefits outweigh the
costs?

Yes my apologies that this was poorly phrased. I was aiming for a pithy summary and a clear statement that our goal here is not to significantly impact contributors uninterested in Bazel. My impression is that the GN build has achieved that goal. I definitely agree that any addition to the monorepo should have a clear weighing of costs vs benefits and that the costs are never actually zero. I do think the costs here are really quite low however. I am happy to address your concerns and also think that it is important to note that if additional issues arise we are still agreeing to be on the hook for addressing them (e.g. if in practice this causes some unforseen issue with the release) and deleting this contribution if we cannot do so in a timely manner (`rm -rf utils/bazel` is all it requires).

 

Personally, I do not think we should have alternative build systems in
tree.  However, I still think you should try to propose this as a pitch.
I would much rather this go through a fair process and land than for it
to be rejected based on a contentious thread.

Here is why I'm not convinced this should be in tree:

To me it's not clear why having the build files in-tree is better than
having a separate repo with an llvm-project sub-module.  The in tree
bazel files will be broken from time to time, since most developers will
not be updating them, however, with the sub-module approach you can
ensure that the build will always work by pinning the llvm-bazel repo to
a known-working commit of llvm-project.  Can you expand on the pros/cons
of in-tree vs out-of-tree with sub-modules.

Out-of-tree with a submodule is the current approach we have with https://github.com/google/llvm-bazel. It's certainly doable, but involves quite a bit of bookkeeping to track which version corresponds to a given version of LLVM such that someone can fetch the correct configuration (you'll note that the repository has about 7k tags at the moment). To make things somewhat more complicated, the typical way to fetch something for use in Bazel is with an http_archive which requires one to specify the archive digest to avoid refetching on each build. This doesn't work particularly well with tags that change which commit they point to. I'm not saying these issues aren't solvable, but they add quite a bit of complexity.

I was under the impression that "utils" was actually "llvm/utils", which would be in the same place as GN. I don't think we should treat GN and Bazel as different and I really wouldn't like to have a different quality control (for post commit reviews).

 

If the Bazel commits are too verbose (for example, committing auto-generated code), then we should really clean that up and commit the script that generates them and make that part of the build.

 

I understand the need to move the noise away, but move it too far away and it's no better than in a separate repo.

I am happy to put this in either location and agree it should be in the same place as GN. If we were to decide that it should go `utils/` then I would also propose we move GN to there as well. I believe the GN files were contributed prior to the existence of the monorepo, so a top-level `utils/` wouldn't have been an option. I think living under the root `utils/` directory makes more sense because these are not configurations for only the LLVM subproject (we also build MLIR and Clang with perhaps more to come). I believe it was Mehdi's suggestion that this would help mitigate some of the costs to having it in the monorepo because Tom mentioned commit list traffic as a concern. I don't think I agree that one directory up is akin to a separate repo though :-D

 

That said, this is a really minor point for me. I'm happy to put this wherever people prefer :-)

 

 

A number of people raised the question of "why not a separate repository". This is indeed possible: It's what we've done with https://github.com/google/llvm-bazel, which is currently used by https://github.com/google/iree. It is significantly more infrastructure, coordination, and complexity for something that is specifically a configuration for the LLVM project itself, not its own dependent or adjacent project.

 

I was also under the impression that one of the big reasons why we needed it to be in LLVM is that, like CMake, it needed files all over the place. This would indeed be a major infrastructure undertaking.

 

But given that it's all being hosted in a single directory, and outside of the LLVM tree, I really can't see what's so much harder about an extra checkout in the same tree.

Bazel *wants* the build files to be all over the place, but I've tricked it with some repository rule symlinking. That's also true of the LLVM GN configuration, I believe. My assumption is that having BUILD files actually throughout the repository would be something that would receive quite a bit of pushback and would be confusing for people who would naturally expect these BUILD files to be maintained as a supported build system. I would happily put a BUILD.bazel file at the root of each subproject and drop the symlinking madness, but I suspect this would not be embraced as a solution ;-P

 

I believe this contribution will significantly improve the situation for downstream users that use Bazel while having minimal impact on the community at large.

 

It's not clear to me yet if LLVM/Bazel is only used in Google projects or any other non-Google project. All that you listed so far seem to be exclusive to Google.

 

This is not a problem per se, but it does promote the idea that Google could common it up internally instead.

 

The main reasons why it would be upstream are that it's either a product by or requirement to the project itself, or it helps unite cross-industry collaboration that wouldn't be possible otherwise.

 

It's clearly not the former (and why it's in the periphery tier), but it's also not clear it's in the latter either.

 

I can really only speak for Google projects. I have also noticed several other Bazel build configurations in the wild, e.g. PlaidML (Intel) or this bazel_llvm project that I found after someone contributed a doc fix. I believe in the last thread someone from Facebook mentioned that Bazel build files would also be relatively easily translatable to their internal Bazel-derived build system, Buck. Someone from Lyft also expressed interest in using a Bazel build configuration if it was in-tree. But I can't really speak to the motivations, road maps, etc. for any of these people, companies, or projects (if you're reading, please chime in ;-P).

Chris Tetreault via llvm-dev

unread,
Dec 7, 2020, 1:26:04 PM12/7/20
to Renato Golin, Mehdi AMINI, LLVM Dev

Renato,

 

   I feel that adding the support policy was useful. The policy documents expectations, and consequences for non-compliance. This eliminates a whole class of objections that, for the most part, are no longer being made. Honestly, I feel like the support policy settled most of the technical arguments. It requires that the Bazel build files be supported, that they not impact the rest of the codebase, and documents at what point they will be removed. I suppose it should go without saying that they should be high quality. All that remains is semantics, history, and precedence.

 

llvm-dev,

 

   As for escalating to the LLVM proposal process, it seems to me that we have reached an impasse. Stefan seems to be strongly opposed, and as far as I can tell, so are you. I’m not in love with the plan either, though I am prepared to accept any outcome of this RFC at this point. I think Stefan’s objection is valid. Just because we have a policy that enumerates the basic requirements for some non-essential thing to be added, and lists conditions for removal, does not mean that all things that meet the basic requirements should be added. I mean, if “because it meets the basic criteria per the support policy” is enough, then I might as well add an MSBuild project because the one CMake generates isn’t ideal. I’m sure the MS folks that work with LLVM wouldn’t mind a hand-rolled MSBuild project being in tree. I’m sure Apple would like their hand-rolled XCode project back. Maybe the GHC folks want a Shake based build system? There needs to be limits.

 

   As a side note, maybe listing Bazel as an example wasn’t a great idea. I guess if we end up accepting the Bazel build files, then it’s fine. But if it gets rejected, a patch should probably be submitted to remove it as an example from line 100 of SupportPolicy.rst.

 

Thanks,

   Christopher Tetreault

Renato Golin via llvm-dev

unread,
Dec 7, 2020, 1:54:01 PM12/7/20
to Chris Tetreault, LLVM Dev
On Mon, 7 Dec 2020 at 18:26, Chris Tetreault <ctet...@quicinc.com> wrote:

Renato,

 

   I feel that adding the support policy was useful. The policy documents expectations, and consequences for non-compliance. This eliminates a whole class of objections that, for the most part, are no longer being made. Honestly, I feel like the support policy settled most of the technical arguments. It requires that the Bazel build files be supported, that they not impact the rest of the codebase, and documents at what point they will be removed. I suppose it should go without saying that they should be high quality. All that remains is semantics, history, and precedence.


Thanks Chris! I appreciate the feedback. For a moment there I thought I had made things worse.

   As for escalating to the LLVM proposal process, it seems to me that we have reached an impasse. Stefan seems to be strongly opposed, and as far as I can tell, so are you. I’m not in love with the plan either, though I am prepared to accept any outcome of this RFC at this point. I think Stefan’s objection is valid. Just because we have a policy that enumerates the basic requirements for some non-essential thing to be added, and lists conditions for removal, does not mean that all things that meet the basic requirements should be added. I mean, if “because it meets the basic criteria per the support policy” is enough, then I might as well add an MSBuild project because the one CMake generates isn’t ideal. I’m sure the MS folks that work with LLVM wouldn’t mind a hand-rolled MSBuild project being in tree. I’m sure Apple would like their hand-rolled XCode project back. Maybe the GHC folks want a Shake based build system? There needs to be limits.


Open question: has there?

If (there are a sizable part of the community that uses it) and if (they have substantial cost in maintaining it off-tree) and if (the cost of maintaining it in-tree is very low - or it gets kicked out), then (why not?).

To me, the only final question is backports. My answer to that is two-way:
 1. If this is a standard release, the delta is really low and we can pull those files to fix bugs in code that touches it. This will mainly be a problem in build files, not editor configuration or other scripts.
 2. If this is a point release (backports), then we may decide to not backport if it gets muddy. The risk of having a conflict just because of a build file is really really low, and if it does happen, it will be one fix, not all fixes.

In both cases, if this keeps happening, and a sizable sub-community gets angry about it, then it breaks the contract and needs to be refactored to not break as often, or be removed. Note that "keeps happening" spanning across releases could take years.

Tom, does that answer the questions you had?

cheers,
--renato

Eric Christopher via llvm-dev

unread,
Dec 7, 2020, 1:57:15 PM12/7/20
to Chris Tetreault, LLVM Dev
Sweet, thanks for the message. It's really appreciated. If you do see any problems please let me or someone else know as the ease of llvm upstream development is something I care deeply about.

-eric

_______________________________________________

Chris Tetreault via llvm-dev

unread,
Dec 7, 2020, 2:34:40 PM12/7/20
to Renato Golin, LLVM Dev

Don’t let Them keep you down. There will always be detractors, but you took concrete action to remove a roadblock to consensus, and I feel that this should be commended. Especially since you did so by writing a bunch of documentation, and I’m sure you had things you’d rather be doing.

 

I think the policy is pretty good, regardless of the outcome for Bazel.

 

Thanks,

   Christopher Tetreault

 

From: Renato Golin <reng...@gmail.com>
Sent: Monday, December 7, 2020 10:54 AM
To: Chris Tetreault <ctet...@quicinc.com>
Cc: Mehdi AMINI <joke...@gmail.com>; LLVM Dev <llvm...@lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] RFC: Contributing Bazel BUILD files in the "peripheral" support tier

 

On Mon, 7 Dec 2020 at 18:26, Chris Tetreault <ctet...@quicinc.com> wrote:

Eric Christopher via llvm-dev

unread,
Dec 8, 2020, 3:40:24 PM12/8/20
to Renato Golin, Geoffrey Martin-Noble, Tom Stellard, LLVM Dev
+Geoffrey Martin-Noble  and +Tom Stellard 

In my effort to smooth the process out here I spoke with Tom offline and we've agreed that a pitch proposal seems to be the best way forward.  From our discussion I believe that he disagrees with adding unsupported build systems to llvm and what methodology we should use to determine their or similar multiple versions of functionality inclusion (please do correct me if I'm wrong here). I think it makes sense to limit the discussion in the pitch to adding unsupported build systems.

My personal take on this and why I've been helping shepherd this along: 

I believe that we should be enabling other people to do work in llvm as long as 

 a) it doesn't impact maintainability of the core system (open to debate in some ways), 
 b) they have a history/desire to be responsible maintainers, and 
 c) it's easy enough to remove if it becomes an issue.

and that doing this helps llvm be used more easily in other projects; thus helping see it's inclusion in more projects, a goal of the project as a whole.

Thanks!

-eric

Geoffrey Martin-Noble via llvm-dev

unread,
Dec 8, 2020, 7:00:59 PM12/8/20
to Eric Christopher, LLVM Dev
Thanks everyone. I will move forward with a pitch as part of the proposal process.

The reason I reopened this as an RFC was because I thought the more general questions should have been resolved as part of the discussion in Renato's support policy RFC and that therefore this would not necessarily be controversial to the point we couldn't resolve it as part of an RFC. (In particular, some people said their objections were resolved by the existence of an explicit policy). Apologies that that took this thread in a direction that lost focus.

Mehdi AMINI via llvm-dev

unread,
Dec 8, 2020, 8:47:19 PM12/8/20
to Eric Christopher, LLVM Dev
On Tue, Dec 8, 2020 at 12:40 PM Eric Christopher <echr...@gmail.com> wrote:
+Geoffrey Martin-Noble  and +Tom Stellard 

In my effort to smooth the process out here I spoke with Tom offline and we've agreed that a pitch proposal seems to be the best way forward.  From our discussion I believe that he disagrees with adding unsupported build systems to llvm and what methodology we should use to determine their or similar multiple versions of functionality inclusion (please do correct me if I'm wrong here). I think it makes sense to limit the discussion in the pitch to adding unsupported build systems.

I still have strong concerns here: "he disagrees with adding unsupported build systems to llvm".
It seems that you're going for a pitch which is 1) not about this proposal in particular and 2) about a point that has been explicitly discussed and written down in the "community support policy".

This also somehow does not align with Tom's last email in this thread: 

> My understanding of the policy is that these categories of things still need to be approved in order to be added to the tree.

This acknowledged the policy, and I believe acknowledged that each individual proposal is discussed on its own merits. The opposition solely based on the principle of disagreeing "with adding unsupported build systems to llvm" is completely off here. Why are we writing our community policy as a guideline of what is/isn't OK if we have to escalate continuously?
I still strongly believe that this is not an OK strategy here.

Best,

-- 
Mehdi

Tom Stellard via llvm-dev

unread,
Dec 8, 2020, 10:10:01 PM12/8/20
to Mehdi AMINI, Eric Christopher, LLVM Dev
On 12/8/20 5:46 PM, Mehdi AMINI wrote:
>
>
> On Tue, Dec 8, 2020 at 12:40 PM Eric Christopher <echr...@gmail.com
> <mailto:echr...@gmail.com>> wrote:
>
> +Geoffrey Martin-Noble <mailto:gc...@google.com>  and +Tom Stellard
> <mailto:tste...@redhat.com>

>
> In my effort to smooth the process out here I spoke with Tom offline
> and we've agreed that a pitch proposal seems to be the best way
> forward.  From our discussion I believe that he disagrees with
> adding unsupported build systems to llvm and what methodology we
> should use to determine their or similar multiple versions of
> functionality inclusion (please do correct me if I'm wrong here). I
> think it makes sense to limit the discussion in the pitch to adding
> unsupported build systems.
>
>
> I still have strong concerns here: "he disagrees with adding unsupported
> build systems to llvm".
> It seems that you're going for a pitch which is 1) not about this
> proposal in particular and 2) about a point that has been explicitly
> discussed and written down in the "community support policy".
>
> This also somehow does not align with Tom's last email in this thread:
>
> > My understanding of the policy is that these categories of things
> still need to be approved in order to be added to the tree.
>
> This acknowledged the policy, and I believe acknowledged that each
> individual proposal is discussed on its own merits. The opposition
> solely based on the principle of disagreeing "with adding unsupported
> build systems to llvm" is completely off here. Why are we writing our
> community policy as a guideline of what is/isn't OK if we have to
> escalate continuously?
> I still strongly believe that this is not an OK strategy here.
>

I don't think we should have alternative build systems in tree. I am
not the only one who has expressed concerns about this. I also don't
think me or anyone else should be able to unilaterally NAK a proposal.
This is why I am suggesting that we use the LLVM Proposal Process.

I really don't want to spend any more time debating this on the mailing
list, because I don't think we are making any forward progress. If you
believe my objections are not in line with the existing policy, then
feel free to move forward with this as an RFC.

In the end, I'm just giving my opinion on what I think is in the best
interest of the community. It is OK with me if other people disagree or
the community decides to go another direction. I know not everyone has
the same perspective as me, and different perspectives are what make
communities strong.

-Tom

_______________________________________________

Mehdi AMINI via llvm-dev

unread,
Dec 8, 2020, 10:20:09 PM12/8/20
to Tom Stellard, LLVM Dev
I believe the policy is *very explicit* and leaves no doubt on the topic right now, it explicitly mentions alternative build systems.
I don't understand why you didn't raise your concern with respect to the policy.

I mostly object to the fact that this proposal can't be discussed on it's own because you're addressing your disagreement with the policy in this thread and in the context of this proposal.
If you think that we shouldn't have any alternative build systems in tree, then I believe that you should start an RFC (/proposal) to amend the policy instead. 
I also believe that it is also perfectly fine to put this current RFC on hold in order to address your more general objection (if you want to pursue such a proposal). This seems like it would have to address the existence of GN build files.

Best,

-- 
Mehdi

Tom Stellard via llvm-dev

unread,
Dec 8, 2020, 10:31:29 PM12/8/20
to Mehdi AMINI, LLVM Dev
On 12/8/20 7:19 PM, Mehdi AMINI wrote:
>
>
> On Tue, Dec 8, 2020 at 7:09 PM Tom Stellard <tste...@redhat.com
> <mailto:tste...@redhat.com>> wrote:
>
> On 12/8/20 5:46 PM, Mehdi AMINI wrote:
> >
> >
> > On Tue, Dec 8, 2020 at 12:40 PM Eric Christopher
> <echr...@gmail.com <mailto:echr...@gmail.com>
> > <mailto:echr...@gmail.com <mailto:echr...@gmail.com>>> wrote:
> >
> >     +Geoffrey Martin-Noble <mailto:gc...@google.com
> <mailto:gc...@google.com>>  and +Tom Stellard
> >     <mailto:tste...@redhat.com <mailto:tste...@redhat.com>>

I'm not going to write my own RFC/proposal, so you don't need to put
this RFC on hold.

-Tom

> >     <mailto:reng...@gmail.com <mailto:reng...@gmail.com>>> wrote:
> >
> >         On Sun, 6 Dec 2020 at 04:38, Mehdi AMINI
> <joke...@gmail.com <mailto:joke...@gmail.com>

> >         <mailto:joke...@gmail.com

_______________________________________________

Stella Laurenzo via llvm-dev

unread,
Dec 9, 2020, 2:21:26 AM12/9/20
to Geoffrey Martin-Noble, LLVM Dev
+1 to making this a pitch - This thread seems deadlocked to me (with plenty of evidence that everyone is acting in what they see is in the best interests of the community and having a legitimate disagreement). In my experience, as well, when a discussion gets to this phase and there is still a strong objection by one or two parties still willing to make it (which can be exhausting to hold such lines), there are almost always more people who share the viewpoint but don't want to get involved. Best to follow a real process towards resolution when things get to that level. I dislike discussions of attrition and would welcome a process for resolving this one. We feel uncomfortably close to attempting to "get this through on a technicality" (full disclosure: I would benefit from such an outcome), and I don't think that would be a success -- it is alienating. We've got a process for deciding such things. Let's use it and then live with the outcome.

_______________________________________________

Renato Golin via llvm-dev

unread,
Dec 9, 2020, 6:08:04 AM12/9/20