From: Brad Smith Subject: Re: [revision] devel/boost: Install BoostConfig.cmake To: Johannes Thyssen Tishman , ports@openbsd.org Date: Sun, 2 Mar 2025 00:20:07 -0500 On 2025-03-01 5:26 a.m., Johannes Thyssen Tishman wrote: > 2025-02-28T17:10:44+0000 Johannes Thyssen Tishman: >> 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? 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. Usually cp(1) isn't used for an install target. Probably better to copy the pax / find example a bit above that.