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