Le Sat, Mar 01, 2025 at 10:26:23AM +0000, Johannes Thyssen Tishman a écrit :
> 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

fwiw, with that patch i can finally configure an upcoming port of
https://sfcgal.gitlab.io/SFCGAL/:

-- Found Boost: /usr/local/lib/cmake/Boost-1.84.0/BoostConfig.cmake
   (found suitable version "1.84.0", minimum required is "1.66")

so that's a welcome addition !