Geoffrey Martin-Noble via llvm-dev
2021-Jun-16 18:14 UTC
[llvm-dev] [PROPOSAL] Add Bazel Build Configuration to the LLVM Monorepo
I'd like to follow up here because the patch to introduce these files has been updated and available for review for some time now (about 3 weeks) without reviewer attention. Could interested parties please take a look? On Thu, Mar 25, 2021 at 6:33 PM Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi Adrian, > > This proposal is not changing the LLVM build system. We are sticking with > cmake. This is just checking in some extra files into the repository to > help out a sub community that cares about bazel. As others mentioned, this > was discussed in depth in the proposal and related threads, > > -Chris > > > On Mar 25, 2021, at 1:10 PM, John Paul Adrian Glaubitz via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hello David! > > > > On 3/25/21 7:12 PM, David Blaikie wrote: > >> (full disclosure, I am a Google employee) > >> > >> I don't think this is appropriate content, communication, or tone for > the > >> LLVM community. > > > > Since English is not my native language, my wording may not convey 100% > what I'm > > trying to say and my tone may seem inappropriate. However, is not my > intention to > > be rude, I'm just trying to raise some concerns given the current state > of Bazel > > and the personal experiences I made with some Google projects in the > past. > > > >>> Looking at the amount of copy-and-paste code in Bazel [1], I'm not > really > >>> convinced > >>> that the code quality of Bazel speaks for itself. > >>> > >> > >> This patch doesn't seem to me to be reflective of "good" or "bad" code, > nor > >> has anyone made any claim about the code quality of Bazel. It isn't > >> relevant to this discussion. > > > > My personal concern is that Bazel will eventually have an impact on the > portability > > of LLVM or any other projects that adopt it like Chromium did in the > past with project > > adopting it as their HTML rendering engine. Looking at the current build > status of Bazel > > in Debian, it builds on 6 of the 23 architecture/platform combinations > that Debian > > supports, > > > >> > https://buildd.debian.org/status/package.php?p=bazel-bootstrap&suite=sid > > > > which I find rather suboptimal for a build system. The build system > should not be > > the limiting factor when it comes to portability and I know no other > build system > > besides "gn" which has similar portability issues. cmake, meson, scons, > qmake and > > so on don't have these portability limitations. They just work on any > target you > > compile them for and they can also easily be bootstrapped. > > > > For "gn", I needed to download a prebuilt build-enviroment (IIRC a whole > chroot) to > > build it from source back then. I don't know if that has changed in the > meantime. > > > >>> I wish it would be more balanced and Google would allow patches in > >>> Chromium or V8 > >>> to support more architectures if - on the other hand - they ask other > >>> upstream > >>> projects to carry support for their usecases. > >> > >> These seem like unhelpful ad-hominem criticisms that aren't relevant to > the > >> matter being discussed. This proposal has been specifically designed to > be > >> minimally impactful to the community (should only be "there are some > more > >> commits to the project/more commit list emails" - and if gn is anything > to > >> go by, not many (<0.1% I'd wager, at a rough guess)). > > > > I don't think that stating facts are ad-hominem attacks. I made similar > experiences > > with Google projects and I found these experiences frustrating. In > particular, one > > of the experiences was an endianness issue with Skia [1] which has also > seen wider > > adoption in other projects which means missing portability hurts the > portability of > > these projects. There was also a SPARC port for Go which got rejected > due to lack of > > interest by the upstream project and the POWER port of Chromium [2] > which got never > > merged for whatever reason. As a result, any project that adopts any of > these technologies > > will reduce its portability. > > > > KMail, KDE's email client, for example used to be highly portable and > was available > > of all of Debian's supported architectures/platforms. Nowadays, KMail > just runs > > on the few architectures that Chromium supports which I consider a step > backwards. > > > > So I personally would like to see that Bazel becomes as portable as any > other commonly > > used build system before it is advertised as a versatile and advanced > build system so > > that it's not going to have the same impacts on portability as Chromium > does. > > > > Adrian > > > >> [1] https://bugs.chromium.org/p/skia/issues/detail?id=7808 > >> [2] > https://groups.google.com/a/chromium.org/g/chromium-dev/c/MYq1DPz9Tak > > > > -- > > .''`. John Paul Adrian Glaubitz > > : :' : Debian Developer - glaubitz at debian.org > > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210616/08d307c7/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3992 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210616/08d307c7/attachment.bin>
David Blaikie via llvm-dev
2021-Jun-17 05:39 UTC
[llvm-dev] [PROPOSAL] Add Bazel Build Configuration to the LLVM Monorepo
Might be good to include a link to the review. (at a glance I don't see a link to it in your email here) On Wed, Jun 16, 2021 at 11:14 AM Geoffrey Martin-Noble via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I'd like to follow up here because the patch to introduce these files has > been updated and available for review for some time now (about 3 weeks) > without reviewer attention. Could interested parties please take a look? > > On Thu, Mar 25, 2021 at 6:33 PM Chris Lattner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Adrian, >> >> This proposal is not changing the LLVM build system. We are sticking >> with cmake. This is just checking in some extra files into the repository >> to help out a sub community that cares about bazel. As others mentioned, >> this was discussed in depth in the proposal and related threads, >> >> -Chris >> >> > On Mar 25, 2021, at 1:10 PM, John Paul Adrian Glaubitz via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> > >> > Hello David! >> > >> > On 3/25/21 7:12 PM, David Blaikie wrote: >> >> (full disclosure, I am a Google employee) >> >> >> >> I don't think this is appropriate content, communication, or tone for >> the >> >> LLVM community. >> > >> > Since English is not my native language, my wording may not convey 100% >> what I'm >> > trying to say and my tone may seem inappropriate. However, is not my >> intention to >> > be rude, I'm just trying to raise some concerns given the current state >> of Bazel >> > and the personal experiences I made with some Google projects in the >> past. >> > >> >>> Looking at the amount of copy-and-paste code in Bazel [1], I'm not >> really >> >>> convinced >> >>> that the code quality of Bazel speaks for itself. >> >>> >> >> >> >> This patch doesn't seem to me to be reflective of "good" or "bad" >> code, nor >> >> has anyone made any claim about the code quality of Bazel. It isn't >> >> relevant to this discussion. >> > >> > My personal concern is that Bazel will eventually have an impact on the >> portability >> > of LLVM or any other projects that adopt it like Chromium did in the >> past with project >> > adopting it as their HTML rendering engine. Looking at the current >> build status of Bazel >> > in Debian, it builds on 6 of the 23 architecture/platform combinations >> that Debian >> > supports, >> > >> >> >> https://buildd.debian.org/status/package.php?p=bazel-bootstrap&suite=sid >> > >> > which I find rather suboptimal for a build system. The build system >> should not be >> > the limiting factor when it comes to portability and I know no other >> build system >> > besides "gn" which has similar portability issues. cmake, meson, scons, >> qmake and >> > so on don't have these portability limitations. They just work on any >> target you >> > compile them for and they can also easily be bootstrapped. >> > >> > For "gn", I needed to download a prebuilt build-enviroment (IIRC a >> whole chroot) to >> > build it from source back then. I don't know if that has changed in the >> meantime. >> > >> >>> I wish it would be more balanced and Google would allow patches in >> >>> Chromium or V8 >> >>> to support more architectures if - on the other hand - they ask other >> >>> upstream >> >>> projects to carry support for their usecases. >> >> >> >> These seem like unhelpful ad-hominem criticisms that aren't relevant >> to the >> >> matter being discussed. This proposal has been specifically designed >> to be >> >> minimally impactful to the community (should only be "there are some >> more >> >> commits to the project/more commit list emails" - and if gn is >> anything to >> >> go by, not many (<0.1% I'd wager, at a rough guess)). >> > >> > I don't think that stating facts are ad-hominem attacks. I made similar >> experiences >> > with Google projects and I found these experiences frustrating. In >> particular, one >> > of the experiences was an endianness issue with Skia [1] which has also >> seen wider >> > adoption in other projects which means missing portability hurts the >> portability of >> > these projects. There was also a SPARC port for Go which got rejected >> due to lack of >> > interest by the upstream project and the POWER port of Chromium [2] >> which got never >> > merged for whatever reason. As a result, any project that adopts any of >> these technologies >> > will reduce its portability. >> > >> > KMail, KDE's email client, for example used to be highly portable and >> was available >> > of all of Debian's supported architectures/platforms. Nowadays, KMail >> just runs >> > on the few architectures that Chromium supports which I consider a step >> backwards. >> > >> > So I personally would like to see that Bazel becomes as portable as any >> other commonly >> > used build system before it is advertised as a versatile and advanced >> build system so >> > that it's not going to have the same impacts on portability as Chromium >> does. >> > >> > Adrian >> > >> >> [1] https://bugs.chromium.org/p/skia/issues/detail?id=7808 >> >> [2] >> https://groups.google.com/a/chromium.org/g/chromium-dev/c/MYq1DPz9Tak >> > >> > -- >> > .''`. John Paul Adrian Glaubitz >> > : :' : Debian Developer - glaubitz at debian.org >> > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de >> > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210616/a0086ea9/attachment.html>