2025-03-08T02:15:51-0500 Brad Smith <b...@comstyle.com>: > On 2025-03-02 12:42 p.m., Johannes Thyssen Tishman wrote: > > 2025-03-02T00:20:07-0500 Brad Smith<b...@comstyle.com>: > > > On 2025-03-01 5:26 a.m., Johannes Thyssen Tishman wrote: > > > > 2025-02-28T17:10:44+0000 Johannes Thyssen Tishman<j...@openbsd.org>: > > > > > From [1]: > > > > > > CMake 3.29 and below provide a FindBoost module, but it needs > > > > > > constant > > > > > > updates to keep up with upstream Boost releases. Upstream Boost 1.70 > > > > > > and above provide a BoostConfig.cmake package configuration file. > > > > > > find_package(Boost CONFIG) finds the upstream package directly, > > > > > > without the find module. > > > > > > > > > > > > CMake 3.30 and above prefer to not provide the FindBoost module so > > > > > > that find_package(Boost) calls, without the CONFIG or NO_MODULE > > > > > > options, find the upstream BoostConfig.cmake directly. This policy > > > > > > provides compatibility for projects that have not been ported to use > > > > > > the upstream Boost package. > > > > > > > > > > > > The OLD behavior of this policy is for find_package(Boost) to load > > > > > > CMake's FindBoost module. The NEW behavior is for > > > > > > find_package(Boost) > > > > > > to search for the upstream BoostConfig.cmake. > > > > > > > > > > > > This policy was introduced in CMake version 3.30. It may be set by > > > > > > cmake_policy() or cmake_minimum_required(). If it is not set, CMake > > > > > > warns, and uses OLD behavior. > > > > > So if a project explicitly sets a policy version >= 3.30, CMake won't > > > > > look for the FindBoost.cmake module installed by devel/cmake/core and > > > > > will instead look for the BoostConfig.cmake file which our devel/boost > > > > > does not install. > > > > > > > > > > I bumped into this issue in my last two port updates (graphics/pcl and > > > > > devel/cli11), so I'd like to propose installing the BoostConfig.cmake > > > > > and related CMake files provided by upstream. I assume we will have to > > > > > do this sooner or later anyways. > > > > > > > > > > The patch 'patch-tools_boost_install_boost-install_jam' is hacky, but > > > > > without it the relative path to the 'include' directory that's > > > > > generated > > > > > in the CMake files ends up pointing to /usr (e.g. [2] line 26) and I > > > > > couldn't figure out why. I'd be happy to see a better solution. > > > > > > > > > > If this revision is acceptable, would it be possible to run it > > > > > through a > > > > > bulk? I tested both graphics/pcl (with a patch to fix finding boost > > > > > removed) and devel/cli11 with the changes below and had no issues. > > > > > > > > > > [1]https://cmake.org/cmake/help/latest/policy/CMP0167.html#policy:CMP0167 > > > > > [2] /usr/local/lib/cmake/boost_atomic-1.84.0/boost_atomic-config.cmake > > > > Please find below a revised patch with the following feedback addressed: > > > > > > > > - boost*-config.cmake files associated with libraries only shipped by > > > > the -md subpackage have now been moved to their corresponding > > > > PLIST-md > > > > - Add VERSION to SUBST_VARS to avoid PLIST churn on updates > > > > - As requested, remove rsadowski@ from the MAINTAINER > > > What was the reason for moving the SO_VERSION change from Jamroot to > > > boostcpp.jam? > > To patch the library versions *only* and not boost's overall version. > > With the Jamroot patch, CMake files would be installed under > > /usr/local/lib/cmake/{Boost-23.0,boost_*-23.0}/. > > > > > That boost-install.jam patch is annoying as it just points to > > > something not being right somewhere else. The patch should have a > > > brief comment at the top. > > I agree, I just haven't been able to find out how the relative path to > > the 'include' directory in the CMake files (e.g. see [2] line 26) is > > being generated. From what I read in Jamroot, bootstrap.sh and > > lib/config/configure, 'includedir' already defaults to > > ${LOCALBASE}/include and passing --includedir=${LOCALBASE}/include or > > --prefix=${LOCALBASE} (redundant) does not help. Maybe you can find a > > better solution. > > > > > Usually cp(1) isn't used for an install target. Probably better to > > > copy the pax / find example a bit above that. > > See diff below with your feedback addressed. > > > Thanks. LGTM. OK.
Committed, thanks!
