Hi Jason, I have been seeing several PRs which I believe are separately preparing the field for Bazel. For example: https://github.com/gem5/gem5/pull/2421/commits/4bcb4fe25d5615fd7f561936e2e3b4925edbe745 This comes as a surprise to me as I thought there was a slight preference over CMake, the latter being a more widely used building tool in the software world. If your team (or yourself only) wants to push a RFC for Bazel support, I think it would be easier for reviewers if it would come with a single PR (similarly to what we have been requesting in the past for Kconfig). Unless the change is something unambiguous that would make sense regardless of the building-tool choice. In this way it would be easier to review and understand what a series of patches are aiming for. That goes without saying it would also democratize the choice between CMake and Bazel, and not presenting the latter at the end of the PRs as a “fait accompli” (not that I am necessarily against Bazel, I consider it a viable option). Looking forward to hearing from you Giacomo IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Hi Giacomo, > In this way it would be easier to review and understand what a series of patches are aiming for. All of the PRs that I've been pushing (#2403-#2409) are simply general cleanup PRs. There is no specific goal of this series of patches. As you said, we have made no community decision on whether to support Bazel, cmake, or do nothing. That said, I believe these PRs will make it easier to move away from scons to either Bazel or cmake in the future. If you want to know the inside story, these PRs are things that were internal changes to gem5 that I am now pushing upstream. By pushing these things upstream, my team and I will have to maintain fewer internal patches. I believe all of these PRs should be non-controversial. They shouldn't affect any APIs, and they shouldn't add any maintenance burden. (In fact, they should reduce the maintainance in the long-run.) For the commit in question, if you want, I can drop the change to the .gitignore. I don't think it hurts anything, but I can drop it. I would appreciate reviews on the PRs. I believe they are self-contained and have clear commit messages explaining their purpose and enabling straightforward reviewing, but if not, please let me know on the PR in question. Cheers, Jason On Mon, Jul 7, 2025 at 5:25 AM Giacomo Travaglini < Giacomo.Travaglini@arm.com> wrote: > Hi Jason, > > > > I have been seeing several PRs which I believe are separately preparing > the field for Bazel. > > > > For example: > > > https://github.com/gem5/gem5/pull/2421/commits/4bcb4fe25d5615fd7f561936e2e3b4925edbe745 > > > > This comes as a surprise to me as I thought there was a slight preference > over CMake, the latter being a more widely used building tool in the > software world. If your team (or yourself only) wants to push a RFC for > Bazel support, I think it would be easier for reviewers if it would come > with a single PR (similarly to what we have been requesting in the past for > Kconfig). > > Unless the change is something unambiguous that would make sense > regardless of the building-tool choice. > > In this way it would be easier to review and understand what a series of > patches are aiming for. > > > > That goes without saying it would also democratize the choice between > CMake and Bazel, and not presenting the latter at the end of the PRs as a > “fait accompli” (not that I am necessarily against Bazel, I consider it a > viable option). > > > > Looking forward to hearing from you > > > > Giacomo > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. >