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.
