On 12. 6. 25 19:30, Daniel Sahlberg wrote:
Den ons 11 juni 2025 kl 17:12 skrev Branko Čibej <br...@apache.org>:
On 11. 6. 25 00:07, rin...@apache.org wrote:
Author: rinrab
Date: Tue Jun 10 22:07:50 2025
New Revision: 1926350
URL:http://svn.apache.org/viewvc?rev=1926350&view=rev
<http://svn.apache.org/viewvc?rev=1926350&view=rev>
Log:
cmake: Prevent re-definition of APR and Serf targets by using different
prefixes for version '1' and '2'.
* CMakeLists.txt
(APR, Serf): Bunch of cmake magic.
Modified:
subversion/trunk/CMakeLists.txt
After the pkg-config related changes, cmake will no longer find a
Serf on macOS. This worked before, but now Serf_ROOT is ignored if
we happen to find pkg-config. That's because you use either
find_package or pkg_find_package, but never both. I have to
explicitly disable SVN_USE_PKG_CONFIG in order to build again.
Looks like a regression to me.
-- Brane
If I understand the issue here, pkg-config support was added in
r1926344 <https://svn.apache.org/r1926344>. The commit message doesn't
explicitly say so, but I suspect it was done because of Thomas Orgis'
rant about CMake[1].
There was some discussion and additional commits adding support for
serf and apr later on.
Is the issue here that macOS has pkg-config, but the version of Serf
that is available (I'm assuming Homebrew or macPorts) doesn't have
pkg-config support?
This particular case was me trying to use a libserf that I'd built
myself and installed to a non-default path -- a fairly common situation
during development. Then I set the Serf_ROOT CMake variable to that
prefix, which worked fine just a few hours previous; because CMake's
find_package() machinery uses that as one of the hints for finding
packages. Its pkg-config machinery, however, doesn't. I have pkg-config
installed for other reasons, and Serf does generate a pkg-config file,
but CMake (or rather, pkg-config) didn't know here to look for it. I
suspect (but haven't tested) that setting PKG_CONFIG_PATH might be a
solution.
The issue is more that this violates the principle of least surprise: if
I use CMake, then I expect that setting SomePackage_ROOT will let CMake
find SomePackage. It's not intuitive that this expectation becomes false
if I also happen to have pkg-config in my $PATH.
If my understanding of the situation is correct, would something like
this (pseudocode/pseudopatch) help?
[[[
### Serf
if (SVN_ENABLE_RA_SERF)
if(SVN_USE_PKG_CONFIG)
pkg_check_modules(serf1 IMPORTED_TARGET serf-1)
if(serf1_FOUND)
# serf-1
add_library(external-serf ALIAS PkgConfig::serf1)
else()
# serf-2
pkg_check_modules(serf2 IMPORTED_TARGET serf-2)
+ if(serf2_FOUND)
add_library(external-serf ALIAS PkgConfig::serf2)
+ else()
+ find_package(Serf REQUIRED)
+ add_library(external-serf ALIAS Serf::Serf)
+ endif()
endif()
else()
find_package(Serf REQUIRED)
add_library(external-serf ALIAS Serf::Serf)
endif()
endif()
]]]
Unfortunately I don't have a Mac to test...
I'm not even sure that preferring pkg-config over CMake's "native"
find_package() mechanism is the right choice. I'd have expected the
logic to go the other way: try find_package() and only if that doesn't
work and pkg-config is available, try pgk_find_package(). Then it would
probably sufficient to document that setting PKG_CONFIG_PATH can control
the outcome in this situation.
-- Brane
