Chris Tetreault via llvm-dev
2020-Oct-29 19:28 UTC
[llvm-dev] Contributing Bazel BUILD files similar to gn
Could not a public repository for the Bazel build system be created, that has a submodule for the llvm monorepo? Users of the Bazel build system could checkout the Bazel build repo and do the submodule init, and this public repo could be used for collaboration. Thanks, Christopher Tetreault From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of David Blaikie via llvm-dev Sent: Thursday, October 29, 2020 12:16 PM To: Renato Golin <rengolin at gmail.com> Cc: Mehdi Amini <aminim at google.com>; LLVM Dev <llvm-dev at lists.llvm.org>; Stella Laurenzo <laurenzo at google.com>; Tres Popp <tpopp at google.com>; Geoffrey Martin-Noble <gcmn at google.com>; Thomas Joerg <tjoerg at google.com> Subject: [EXT] Re: [llvm-dev] Contributing Bazel BUILD files similar to gn On Thu, Oct 29, 2020 at 9:06 AM Renato Golin via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On Thu, 29 Oct 2020 at 15:23, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: I'm a little concerned about having two 'unsupported' buildsystems living in tree, and I'm not sure what would stop us from continuing to add more. I would feel better if we had a set of guidelines to define the criteria for adding a new buildsytem and also criteria for when we can remove them. I have used Bazel and it doesn't seem to map well to CMake. It seems to be in between CMake and Ninja with a lot of hard-coded dependencies that are cumbersome to keep updating. I'm by no means an expert, and I could very well be wrong, but supporting more than one build system is not trivial (remember the autoconf days?). For example, when trying to implement the same logic on both will not be trivial. So, whenever we want to add some functionality or improve how we build LLVM with one system, we'll have to do so in multiple build systems that do not easily match each other. If we don't try to match functionality, we'll segregate the community, because people will be able to do X on build system A but not B, and the similar features cluster together and then we have essentially two projects built from the same source code. Testing this, or worse, trying to fix a buildbot that is built with Bazel (and having to install Java JDK and all its dependencies) on potentially a hardware that you do not have access to, will be a nightmare to debug. The nature of post-commit testing, revert and review of LLVM will not make that simpler. Unless we treat the Bazel build as "not our problem" (which defeats the point of having it?). To make matters worse, our CMake files are not simple, and do not do all of the things we want them to do in the way we understand completely. There is a lot of kludge that we carry and with that comes in two categories: the things that we hate and would love to fix, and the things that are fixes that we have no idea are there. The former are the reasons why people want to start a new build system, the latter is why they soon realise that was a mistake (insert XKCD joke here). If the Bazel files can be completely ignored, then it's just more clutter. But if other projects start to use more different build systems and we start packing them all in LLVM, then we'll have a hard time knowing what we build how. I can't really see this scaling. I /believe/ the idea is that, like gn, there are folks maintaining these build systems out of tree anyway - and having them in tree makes it easier to coordinate that effort, with the express intent of not burdening the general community with their upkeep (like gn currently - the idea is that there's no burden on developers to update gn build files (& consequently bazel build files)). So far the gn build inclusion seems to have gone OK, I think? So maybe the Bazel thing would be similar? Sounds like the work is being done out of tree anyway, but having it in-tree makes it a bit easier to coordinate interested parties, while not adversely affecting unrelated parties, I think? Though I'm not sure what the tradeoff/cost of this is compared to having a separate project holding the build files, with LLVM as a git submodule. Not knowing a lot about it, that /sounds/ like it gets most of the benefits/not sure what the costs are? - Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201029/f8108f35/attachment.html>