On Mon, Jun 10, 2024 at 4:03 PM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote: > > Den sön 9 juni 2024 kl 03:00 skrev Nathan Hartman <hartman.nat...@gmail.com>: (snip) >> Hi Timofei, >> >> I am really glad to see this being addressed! >> >> CMake has been requested here before (such as [1], [2], and [3]) and >> the difficulty of building on Windows has been discussed/lamented here >> many times (such as [1]). >> >> I agree with the rationale of keeping the existing build system as-is >> and adding CMake as an option for those who want it. As you said, this >> avoids breaking changes. If it makes life easier and gets us more >> Windows contributors (especially testers at release time), I would >> strongly propose it (I mean: the final, non-draft patch) for backport >> for the 1.14.4 release. > > > I don't see any problems in backporting this to 1.14.4 - it isn't a breaking > change at all and if someone wants to build using CMake, go ahead. > > I still think that we should consider the effort of making a switch - maybe > staggered by adding CMake in 1.14.4, declaring it "preferred" in 1.15 and > remove the old build system in 1.16. I'd just like to avoid a situation where > we have multiple build system generators to maintain.
I am certainly open to exploring this idea (of a full switch to CMake). Potential advantages: * A simpler, more unified build system (across Unix, Windows) * Simplify our INSTALL doc * Support cross-compilation (has been requested) Potential disadvantages: * Initial effort to make the switch -- I assume non-trivial? Do we have the volunteer capacity to do it? * May also require non-trivial effort for 3rd party binary packagers. * Requiring a too-new CMake can cause headaches (explained below). Concerns: Will there be a strong community support for a switch to CMake? We can only know by discussing it. It would be nice to hear from binary packagers. Will they overwhelmingly say "yes please! It's about time!" Or will they say, "Please don't, it would create too much headache and I couldn't go on providing packages because of it." Headaches: I needed to build and install some CMake-based project on my Debian box. It required a newer CMake than was available in Debian's package archive; this led to the side project of getting a new-enough CMake on the machine. Not insurmountable, but adds friction. To help our users/packagers/devs avoid that, I would urge to support a not-too-new CMake, for some to-be-determined value of "not- too-new". 'Staggered' changeover: This is a sensible idea. To consider CMake as 'preferred' for 1.15, we would need to ensure that all use-cases covered by the current build system are fully covered with CMake, including (just thinking out loud): building the bindings and running the test suite. Regarding the test suite, I use tools/dev/unix-build/Makefile.svn. This Makefile is very nice because it can setup and build a full debug- and test-ready dev environment with all dependencies. It can automatically download tarballs of dependencies and check out working copies of SVN if needed. It is easy to test with different versions of the dependencies. To support the test suite, it automatically starts and stops servers (both svnserve and httpd), allowing to test any combination of [local | svn | serf] x [fsfs | bdb], etc. It also runs all the bindings tests. I would like very much to retain this functionality. Other areas to research: Will switching to CMake help us to: * Support SBOM (which looks like it will become mandatory soon) * Support running static analysis? * Dynamic analysis? * Fuzzers? If it does help with any or all of those, that could be a significant thing in favor of switching. Anyway, just a stream of my thoughts/questions/concerns... Cheers, Nathan
