Bug 222207 - [cmake] net/ceph & net/ceph-devel: fails to build with boost 1.65
Summary: [cmake] net/ceph & net/ceph-devel: fails to build with boost 1.65
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Jan Beich
Keywords: patch
Depends on:
Blocks: 220714 224185
  Show dependency treegraph
Reported: 2017-09-11 02:48 UTC by Jan Beich
Modified: 2017-12-08 16:08 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (wjw)

Backport upstream commits (4.66 KB, patch)
2017-09-19 21:33 UTC, Jan Beich
rakuco: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Comment 2 Willem Jan Withagen 2017-09-11 09:49:02 UTC
(In reply to Jan Beich from comment #1)

Yes, this is usually a problem with (ceph) ports using Boost.
When Boost upgrade to a new version, Cmake needs to know about it.

During my development, sort of hacked aroound it until Cmake got the patches.
In the end this is also the better fix for Ceph as well.
Fetching the patches will not fix this, since it will need to be done with Cmake.

But I do not have insight in the plans of the Cmake maintainer.
Perhaps best to prod him?
Comment 3 Willem Jan Withagen 2017-09-12 16:28:49 UTC
(In reply to Willem Jan Withagen from comment #2)

I looked further into this, but as far as I can see is Boost 1.64 the version distributed in packages... So why does a build running 11.0-RELEASE try to fetch 1.65??? For me this is highly unexpected, and the errors are exactly the same as the ones I had when Boost went from 1.63 tot 1.64.
Upgrading Cmake then fixed that, but then Cmake needs to be at a revision that actually includes the indicated patches. I guess that would hold for most tools actually using Boost and not specifying the path for the library manually in the port.

I see that this blocks migration to Boost 1.65??
For which I very sorry.
Is there a way of fixing Cmake? Otherwise I have to start poking in the Cmake-files in Ceph. Which is doable, but not absolutely needed.
Comment 4 Jan Beich freebsd_committer 2017-09-19 21:33:45 UTC
Created attachment 186555 [details]
Backport upstream commits

(In reply to Willem Jan Withagen from comment #3)
> why do es a build running 11.0-RELEASE try to fetch 1.65???

The build log is from an exp-run. Once bug 220714 lands this package would be marked BROKEN unless you prefer pkg-fallout@ spam. AFAIK, there're no testing repos where you can install binary packages for pending port updates.

office@ doesn't seem to plan to maintain more than one version of boost as illustrated by how long it took to land bug 199601. I'm not part of office@ team, if not obvious.
Comment 5 Willem Jan Withagen 2017-09-19 21:57:16 UTC
(In reply to Jan Beich from comment #4)

Life could be simple, but then it never really is.

I'm not really into the version of Boost OR Cmake.
Just as long as a new Boost also updates the versioning in Cmake.

So every time Boost upgrades with the matching Cmake definitions, my ports will break. Which is bad, but I can't do much about it if the Cmake maintainer chooses not to upgrade.

I would consider your patch of rahter limited impact, but then that's me.
It is up to KDE@ to actually "do the right thing"

Other than harassing them over this ....
But I'd expect breakage for everything that mixes Boost and Cmake.
Comment 6 Adriaan de Groot freebsd_committer 2017-09-19 22:14:55 UTC
ok, so what we're seeing is that a new boost version comes out, and then the FindBoost cmake module needs to be updated to actually find that new version, and to find all the right dependencies. That's surprisingly fragile.

Since CMake 3.9 landed last week, updating this Find-module is a lot simpler, though. Thanks for pointing out the upstream commits.

I'm not sure if an exp-run is needed for module-updates .. that is something I'll discuss with my mentors and antoine@.
Comment 7 Raphael Kubo da Costa freebsd_committer 2017-09-20 10:39:23 UTC
(In reply to Adriaan de Groot from comment #6)
> I'm not sure if an exp-run is needed for module-updates .. that is something
> I'll discuss with my mentors and antoine@.

I don't think it is necessary in this case. Those two commits have already been backported to CMake's "release" branch, and I think that's enough to show everything should work.

More context:
* https://gitlab.kitware.com/cmake/cmake/merge_requests/1280
* https://gitlab.kitware.com/cmake/cmake/issues/17289
Comment 8 commit-hook freebsd_committer 2017-09-21 19:59:51 UTC
A commit references this bug:

Author: jbeich
Date: Thu Sep 21 19:59:36 UTC 2017
New revision: 450301
URL: https://svnweb.freebsd.org/changeset/ports/450301

  devel/cmake: backport boost 1.65.1 support

  CMake Warning at /usr/local/share/cmake/Modules/FindBoost.cmake:767 (message):
    Imported targets not available for Boost version 106501
  Call Stack (most recent call first):
    /usr/local/share/cmake/Modules/FindBoost.cmake:871 (_Boost_COMPONENT_DEPENDENCIES)
    /usr/local/share/cmake/Modules/FindBoost.cmake:1501 (_Boost_MISSING_DEPENDENCIES)
    CMakeLists.txt:558 (find_package)

  PR:		222207
  Approved by:	kde (rakuco)
  Obtained from:	upstream (cmake-3.9.3)

Comment 9 Jan Beich freebsd_committer 2017-09-21 20:01:29 UTC
Thanks for feedback. Landed after formatting the patch (no code changes) to better conform to other kde@ backports.