On Sat, Jun 8, 2024 at 7:07 PM Daniel Sahlberg
<daniel.l.sahlb...@gmail.com> wrote:
>
> Hi!
>
> Den lör 8 juni 2024 kl 16:12 skrev Timofey Zhakov <t...@chemodax.net>:
>>
>> Hi all!
>>
>> When I was starting using and developing Subversion, I had a big
>> challenge to build it for the first time, especially because
>> Subversion itself and its dependencies have different build systems,
>> so this is a very complicated process.
>>
>> The build process can be improved by adding a generator for the CMake
>> build system. This can be easily implemented due to the extensibility
>> of the Subversion's gen-make.
>>
>> Some advantages of using CMake in Subversion:
>> - CMake is used by some Subversion dependencies, so there is nothing
>> else to learn.
>> - Great Visual Studio integration for build and tests. In addition,
>> there is a VSCode extension for CMake.
>> - CMake provides a very useful and simple system for finding dependencies.
>> - Better for build scripts and reproducibility of the build.
>>
>> The commands that would be needed to build Subversion, if you have all
>> dependencies installed:
>>
>> ```
>> $ .\gen-make.py -t cmake
>> $ cmake -B out -DCMAKE_INSTALL_PREFIX=/path/to/deps
>> $ cmake --build out
>> ```
>>
>> Additionally, there is a great tool, vcpkg, which can be used to build
>> dependencies. It is integrated with CMake. The following command can
>> be used to install dependencies:
>>
>> ```
>> git clone https://github.com/microsoft/vcpkg
>> cd vcpkg
>> .\bootstrap-vcpkg.bat -disableMetrics
>> .\vcpkg.exe install apr apr-util expat zlib
>> ```
>>
>> I am attaching a draft patch with the implementation of the CMake generator.
>>
>> 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'.
> That said, I'm having some trouble figuring out how to tell CMake where APR
> is installed. I run vcpkg as above in c:\devel, meaning I now have everything
> installed in c:\devel\vcpkg\installed\x64-windows (for example
> c:\devel\vcpkg\installed\x64-windows\include\apr.h). Still I get:
>
> [[[
> C:\Devel\svn_trunk_cmake>cmake -B out
> -DCMAKE_INSTALL_PREFIX=c:\devel\vcpkg\installed\x64-windows
> -- Selecting Windows SDK version 10.0.22621.0 to target Windows 6.2.9200.
> CMake Warning at CMakeLists.txt:38 (find_package):
> By not providing "Findapr.cmake" in CMAKE_MODULE_PATH this project has
> asked CMake to find a package configuration file provided by "apr", but
> CMake did not find one.
>
> ...cut...
> ]]]
>
> I'm sure I'm doing things wrong but I can't figure out what...
Sorry for not mentioning; there is a little problem in APR and APR
util because they don't export CMake targets [1], so the way I used to
link doesn't work with the latest versions. I was using apr-2 (from
trunk), where this was fixed.
There is the same problem with serf, so I didn't implement it in CMake yet.
Another problem that I didn't mention is that it's required to apply
the 'svn-fix-ws2_32.patch.txt' [2]. I duplicated the attachment to the
email.
[1] CMake targets can be exported from the CMake project and they are
used for linking libraries, their dependencies, and setting the
include directories.
[2] https://lists.apache.org/thread/5vc4vj76o8mdkyvyqoqcgc0cjnhpx72k
--
Timofei Zhakov
Index: build.conf
===================================================================
--- build.conf (revision 1918171)
+++ build.conf (working copy)
@@ -298,6 +298,7 @@
libs = libsvn_delta libsvn_subr aprutil apriconv apr libsvn_fs_util
msvc-export = private/svn_fs_fs_private.h ../libsvn_fs_fs/fs_init.h
msvc-delayload = yes
+msvc-libs = ws2_32.lib
[libsvn_fs_x]
description = Subversion FSX Repository Filesystem Library
@@ -307,6 +308,7 @@
libs = libsvn_delta libsvn_subr aprutil apriconv apr libsvn_fs_util
msvc-export = ../libsvn_fs_x/fs_init.h
msvc-delayload = yes
+msvc-libs = ws2_32.lib
# Low-level grab bag of utilities
[libsvn_fs_util]
@@ -378,7 +380,7 @@
libs = aprutil apriconv apr xml zlib apr_memcache
sqlite magic intl lz4 utf8proc macos-plist macos-keychain
msvc-libs = kernel32.lib advapi32.lib shfolder.lib ole32.lib
- crypt32.lib version.lib
+ crypt32.lib version.lib ws2_32.lib
msvc-export =
svn_auth.h svn_base64.h svn_cache_config.h svn_checksum.h svn_cmdline.h
svn_compat.h svn_config.h svn_ctype.h svn_dirent_uri.h svn_dso.h
@@ -445,6 +447,7 @@
path = subversion/svnfsfs
install = bin
libs = libsvn_repos libsvn_fs libsvn_delta libsvn_subr apriconv apr
+msvc-libs = ws2_32.lib
# ----------------------------------------------------------------------------
#
