On 2025-03-02 12:42 p.m., Johannes Thyssen Tishman wrote:
> 2025-03-02T00:20:07-0500 Brad Smith<brad@comstyle.com>:
>> 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?
> 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.