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.cmakePlease 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