Den sön 9 juni 2024 kl 03:00 skrev Nathan Hartman <hartman.nat...@gmail.com >:
> On Sat, Jun 8, 2024 at 2:05 PM Timofey Zhakov <t...@chemodax.net> wrote: > > > > On Sat, Jun 8, 2024 at 7:07 PM Daniel Sahlberg > > <daniel.l.sahlb...@gmail.com> wrote: > > > Den lör 8 juni 2024 kl 16:12 skrev Timofey Zhakov <t...@chemodax.net>: > ... > >> What do you think? > > > > > > > > I think it would be a very good addition to support CMake. Thanks for > bringing this up! > > Thanks! > > > > > I'm just thinking about if it is worth supporting yet another build > generator. The answer I'm looking for is not to shoot down this effort - > rather: > > > * Can we drop any of the existing targets? > > > - vcproj probably can go away since CMake has a higher longterm > chance of creating valid project files for future VS versions. > > > - make, maybe we could switch completely? Are there any compelling > reasons for NOT using CMake to create Makefile? > > > * If we end up deciding to switch - shouldn't we rather rip out the > existing build-system generator architecture? Otherwise we end up in a > situation where we have a configuration (build.conf) and a generator > (gen-make.py and related) creating rulefile(s) for CMake only to have CMake > create rulefile(s) for whatever buildsystem actually used for building. > > > > I agree with you, because the current build system is too hard to > > maintain and it's so complex, but there would be a lot of possible > > breaking changes; some people might prefer to use the older build > > systems, because they are more stable. Additionally, all existing > > scripts won't work. > > > > That's why I decided to generate it by gen-make. Additionally, CMake > > files can be included into release tar-ball like 'configure'. > > > ... > > 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. Kind regards, Daniel > > Caveat: So far I only glanced at the patch quickly; I will provide > actual feedback after I look more carefully and test it. > > By the way, I don't know whether we'd normally allow a new build mode > in a point release, but even if we normally wouldn't, I'd urge us to > consider making an exception because we need more Windows testers. > > References: > > [1] Building SVN on Windows: > dev@ thread "Building SVN (dependencies) on Windows" started 20 Apr > 2020 > https://lists.apache.org/thread/qf1tfohrwjrjk4qm1j1l8z11hfthlcq3 > Notably this response from Wireshark maintainer Graham Bloice: > https://lists.apache.org/thread/qdvl8hdb19fnq75qfx5wmxm5b1ylkdzd > > [2] Building SVN for Synology NAS: > dev@ thread "SVN on Synology" started 17 Aug 2020 > https://lists.apache.org/thread/q85nxhcfq574mxnnt8fdb2v1sxl09d32 > Johan discusses CMake in this reply: > https://lists.apache.org/thread/32kydm0y6826h099xgk48prxn8vbq9p9 > > [3] Building SVN for Android with NDK: > dev@ thread "Cross compiling build instructions" started 15 Oct 2019 > https://lists.apache.org/thread/qqll3l0kcon2k47q8qjyqr4htd9jmz2p > CMake discussed in this follow-up: > https://lists.apache.org/thread/djj5gns3d06t4k0m6mxs2s1zr8xkbgwo > > Your efforts are very much appreciated. > > Thanks, and cheers, > Nathan >
