[MacPorts] #69698: boost @1.76: error: no member named 'result_of' in namespace 'boost'

[MacPorts]

#69698: boost @1.76: error: no member named 'result_of' in namespace 'boost'
----------------------+-----------------------
  Reporter:  Gandoon  |      Owner:  michaelld
      Type:  defect   |     Status:  assigned
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:  2.9.3
Resolution:           |   Keywords:
      Port:  boost    |
----------------------+-----------------------

Comment (by Gandoon):

 Replying to [comment:3 ryandesign]:
 > Replying to [comment:2 Gandoon]:
 > > That is somewhat odd though as both `libtorrent-rasterbar` and
 `qBittorrent` depend on `boost181`:
 >
 > I am aware.
 >
 > Back before we had versioned boost ports (boost176, boost181, etc.) that
 install their headers and libraries into nonstandard directories, we had
 the boost port which installed its headers and libraries into the standard
 directories. Gradually ports were migrated from the unversioned boost port
 to the versioned ones. However, because the boost port installs into
 standard directories, its headers and libraries might be found by build
 systems even though we were intending them to use a different versioned
 boost port's headers and libraries. The problem can be worked around by
 using trace mode (unless you use macOS 13 or newer on Apple Silicon) or by
 deactivating the boost port before building. The problem would go away if
 the boost port were deleted.

 I see.

 Unfortunately I have `vtk @9.3.0_0+ffmpeg+python311+qt5+xdmf` installed
 that depends on the unversioned `boost`, which is why it was installed in
 the first place. As I mentioned, I tried by building a version of
 `boost176` with Clang-14, a configuration known to have worked
 historically for the mentioned for me broken ports. That solved the build
 issue for `libtorrent-rasterbar` but it did still break `qBittorrent`. I
 was unsure if it would have worked if I had deactivated the unversioned
 `boost`, but as `qBittorrent` still failed I tried that route with the
 currently active `boost181
 @1.81.0_10+clang17+cmake_scripts+no_single+no_static+python312`. With the
 unversioned `boost`deactivated in the end `qBittorrent` built as intended
 even though `boost @1.81` was built with `+clang17`. I expected that maybe
 I would have to revert to e.g. `+clang14` for `boost181` as well, but it
 worked. I guess I found a workaround. However, I was, and still am a
 little unsure if the current state will cause any trouble. As it hasn't
 before I guess it will be fine. To be sure I did force a rebuild of
 `libtorrent-rasterbar` with a deactivated unversioned `boost` and it seems
 to build as intended. It remains to be seen if it the ports works as
 intended.

 This was somewhat unintuitive, but at least solvable. As it sounds as if
 the unversioned `boost` should be deprecated, and that there are more than
 one port that `boost` broke, maybe `libtorrent-rasterbar`, `qBittorrent`,
 and any other port that shows this behaviour should have their respective
 Portfiles report a conflict if an unversioned `boost` is installed and
 active? And obviously, `vtk +xdmf` (and possibly others) needs to change
 dependency to the versioned ports. I will have to check if I really need
 the `vtk +xdmf` variant. If not, I could potentially get rid of the
 unversioned `boost` and not run into this issue again.

 Thank you for your input.

-- 
Ticket URL: <https://trac.macports.org/ticket/69698#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS