Date: Wed, 18 Apr 2018 10:10:47 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 227428] devel/cmake: fails to find suffixed libboost_python Message-ID: <bug-227428-7788-BMVxeFMzyu@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-227428-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-227428-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227428 --- Comment #12 from Willem Jan Withagen <wjw@digiware.nl> --- (In reply to Adriaan de Groot from comment #11) If the fix in the Cmake stuff (either FreeBSD specific or not) allows for this call find_package(Boost 1.66 COMPONENTS ${BOOST_COMPONENTS} REQUIRED) to do "the right thing" (tm), then No changes to the ceph-source are needed. As things go now I'll have to add a selector on FreeBSD to append the python-version. No biggie, but again specific code for a specific problem. That said, to has started with a discussion on ceph-dev to determine what t= o do with 2.7 and how fast to fase it out, and make all 3.x code.=20 That could/would leave FreeBSD users that are mainly on 2.7 in the cold. Which should not be a major problem from opperational point, since you do n= ot want to do much other on the ceph storage nodes. It could however conflict = on compute nodes where scripting depends on 2.7 and 2.7 compatible classes. So I'm driven here by what Ceph does in the code, and by FreeBSD packages in what is possible and desirable. And that in the negative time I have availa= ble ATM. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-227428-7788-BMVxeFMzyu>