On Thu, Jun 13, 2024 at 5:01 AM Jun Omae <jun6...@gmail.com> wrote: > > On Wed, Jun 12, 2024 at 5:37 AM Timofey Zhakov <t...@chemodax.net> wrote: > > > 2. > > > gen-make.py accepts --with-PKG=... options like the following, but all > > > options should be passed to cmake -B again. Why CMakeLists.txt is > > > generated instead of adding directly CMakeLists.txt, in the patch? > > > > That's a good question. I decided to just generate the CMake files > > based on build.conf. I think this approach is great because we can > > keep vcnet project files and Unix Makefiles until the CMake can fully > > replace them. The dependency searching is delegated to the CMake, so > > the CMakeLists.txt file can be generated from the release.py script > > and put into release tar-ball like 'configure', because it would not > > contain any paths and options. Additionally, we can also someday just > > simply put the generated CMakeLists.txt file into the repository, > > cut-off the gen-make build system, and use CMake as the main build > > system. > > Thanks for the explanation. That makes sense. Adding CMakeLists.txt file > to release tarball seems to be good to me. > > > 1. You don't need to pass the options to the gen-make command, because > > the dependency searching is done via CMake, so the options are ignored. > > 2. Instead of specifying each include dir and library path, you could > > just specify the CMAKE_INSTALL_PREFIX variable to a path where the > > dependencies are installed. > > I try to use CMAKE_INSTALL_PREFIX variable. However, I think CMakeLists.txt > should have all options corresponding to the --with-PKG of gen-make.py.
I think that this does not follow the CMake dependency finding concepts, because in CMake you usually have an installation directory with all the packages. For example, vcpkg install directory or something similar to the Linux packages directory (/usr/local/bin), where you install all built libraries. I think this is quite useful, because you don't need to always specify the long list of options due to the same install dir. If you have libraries installed in different locations, you can pass all of them to the CMAKE_PREFIX_PATH variable. For example, in your case: [[[ cmake.exe -B out -DCMAKE_PREFIX_PATH=C:/usr/apps/vcpkg/installed/x64-windows-release;C:/usr/src/subversion/win64-vs16/httpd ]]] However, I agree that there should be the options for the prefixes of the specific libraries, to keep the old behaviour. For example, APR_ROOT or APR_ROOT_DIR (this is more in CMake style). The problem is that it would be required to write a lot of custom code, because it is not standard for CMake. I've tried that, but there were some problems. The other solution is to use the <PackageName>_ROOT variable [1], which was added in CMake of version 3.12. It would be searched before the other locations like CMAKE_PREFIX_PATH [2], [3]. > Just tried with the following commands: > [[[ > cmake.exe ^ > -B "C:/usr/src/subversion/trunk-py312/out" ^ > -D CMAKE_BUILD_TYPE=Release ^ > -D CMAKE_PREFIX_PATH=C:/usr/apps/vcpkg/installed/x64-windows-release ^ > -D BUILD_SHARED_LIBS=ON ^ > -D SVN_SQLITE_USE_AMALGAMATION=OFF ^ > -D SVN_USE_INTERNAL_LZ4=ON ^ > -D SVN_USE_INTERNAL_UTF8PROC=ON ^ > -D APR_INCLUDE_DIR=C:/usr/src/subversion/win64-vs16/httpd/include ^ > -D APR_LIBRARY=C:/usr/src/subversion/win64-vs16/httpd/lib/libapr-1.lib ^ > -D APRUTIL_INCLUDE_DIR=C:/usr/src/subversion/win64-vs16/httpd/include ^ > -D > APRUTIL_LIBRARY=C:/usr/src/subversion/win64-vs16/httpd/lib/libaprutil-1.lib > ^ > -D > SQLite3_INCLUDE_DIR=C:/usr/apps/vcpkg/installed/x64-windows-static/include > ^ > -D > SQLite3_LIBRARY=C:/usr/apps/vcpkg/installed/x64-windows-static/lib/sqlite3.lib > ^ > || exit/b 1 > > cmake.exe ^ > --build "C:/usr/src/subversion/trunk-py312/out" ^ > --config Release ^ > --parallel --verbose ^ > -- ^ > -clp:ShowCommandLine -fl -flp:logfile=msbuild.log ^ > || exit/b 1 > ]] > > But I encountered many "unresolved external symbol __imp_htonl" errors. > > [[[ > 6>checksum.obj : error LNK2019: unresolved external symbol > __imp_htonl referenced in function close_handler > [C:\usr\src\subversion\trunk-py312\out\libsvn_subr.vcxproj] > ]]] > > It seems to be caused by missing ws2_32.lib for the linking. I guess > `gen_cmake.py` needs methods like `get_static_win_depends` and > `get_linked_win_depends` in `gen_win.py`? Have you got success to > build on your Windows environment with cmake? As Nathan already said, you have to apply the svn-fix-ws2_32.patch.txt [4] before. Some libraries and programs use the ws2_32.lib but they don't have it in the msvc-libs field. This was working in vcnet but not in CMake due to private dependencies. Could you review it? [1] https://cmake.org/cmake/help/latest/variable/PackageName_ROOT.html [2] https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-search-procedure [3] https://cmake.org/cmake/help/latest/command/find_path.html [4] https://lists.apache.org/thread/5vc4vj76o8mdkyvyqoqcgc0cjnhpx72k -- Timofei Zhakov
