On Thu, Jun 12, 2025 at 8:03 PM Branko Čibej <br...@apache.org> wrote:
> 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 >> 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]. > > Kind of. I think many Linux users and package distributors prefer using pkg-config, because it explicitly tells *how* to actually use the library. Related: cmake has their own configs which do similar things. But most of the libraries don't implement one or it's not available on some package managers (I think FreeBSD or OpenBSD drops Expat's config). > 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. > > I think we can add separate options which will tell each library to use pkg-config explicitly. For example, it will let us consume all libraries from pkg-config, but will handle your Serf installation through the module. > > > 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. > As far as I know it's preferred by Linux users. Again, remember Thomas Orgis' feedback. I wanted to implement that functionality. I think pkg-config should be preferred because it provides the instructions to include the library, based on platform and system dependent factors. For example, there is a chance that some openssl on some weird platform will require an extra library to link against, which our module will never ever handle. > Then it would probably sufficient to document that setting PKG_CONFIG_PATH can control the outcome in this situation. Yea. I think we should generally improve the documentation of our cmake. -- Timofei Zhakov
