Regarding distributed compilation... We can get in touch with ASF to have some VMs for a build farm. That is, we will still run the build locally, though the compilation will be delegated to a cluster of nodes, which in return will speed up the process notably. Back in my graduate days, I was a big fan of distcc. I often used the build farm to test my patches against PostgreSQL – yes, back then I was contributing to PostgreSQL, the good old days.
[Note that I am still negative with regards to Bazel. That said, I am open to discussion.] On Wed, Jun 16, 2021 at 5:50 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > > On Jun 16, 2021, at 8:29 AM, Matt Sicker <boa...@gmail.com> wrote: > > > > I should note some possible benefits we could get from Bazel in theory: > > > > * Ability to offload builds/tests/etc. to remote build clusters. If > > you've ever used things like distcc for compiling things across > > multiple machines (handy for compiling C or C++ binaries for example), > > it sounds similar. > > I don’t get this. When I build locally I only have one machine. With CI we > run the build on as many environments as we want. > > > > * Ability to combine multiple languages together. If we wanted to, > > we'd be able to combine the log4net, log4cxx, and any other future > > subprojects into a single one. This would really only be useful if we > > had a unified configuration format or similar. > > OK, but I would never envision doing this. > > > * More granular builds (should be able to recompile only parts that > changed) > > Maven is supposed to do this. I’ve often wondered why it never works. > > > > > > There are some disadvantages, though: > > > > * No good IDE support yet AFAIK. > > * Build files are somewhat tedious compared to Maven's convention over > > configuration style. > > * Can be over complicated for a project that only uses a single > > programming language or compiler (possibly useful when you need > > multiple versions of Java, but we already have the Maven toolchains > > feature for that). > > * Has a bit of a bootstrapping problem: Bazel seems like it works best > > when everyone around you is also using it. Being able to reuse > > configurations and such is handy. This applies to pretty much any > > build system. > > > > As for the Maven modularity (below), this might be something that can > > be addressed during the plugin system updates (potentially making > > log4j-plugins purely the annotation processor). > > The above isn’t really possible. The annotation processor build, the > annotation > processor runtime, and the plugin system during execution pretty much > share > everything in Log4j-plugins. I believe when it was split from core the > smallest > set of stuff that had to be together was broken out. > > > Ralph > > >
