Saturday, March 01, 2025

Re: [revision] devel/boost: Install BoostConfig.cmake

On 2025-03-01 5:26 a.m., Johannes Thyssen Tishman wrote:
2025-02-28T17:10:44+0000 Johannes Thyssen Tishman <jtt@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?

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.

No comments:

Post a Comment