New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
boost::python::make_setter(&X::y) no longer compiles #39
Comments
This fixes the regression caused by 42e7d7b. Fixes boostorg#39
You could define the "missing" overload in your own code:
|
Thank you for your reply. I already tried that to no avail, which I find quite odd.
|
Looks like you didn't declare the overload everywhere it's needed, since it's not listed as a candidate function. |
(As usual, it might help to put together a minimal test case and share that. Otherwise it's hard to help just by second-guessing.) |
@stefanseefeld The #40 fix works just fine. Yet I would like to make the project aware that boost python 1.59 has an issue and address that with a workaround within the project. |
Yes, I understand. But even if you ask for help on your own code, it's hard to do so without seeing the actual code. (And often enough putting together a test case might in itself reveal the problem, so it's a good strategy anyhow. :-)) |
Be aware that Fedora rawhide (which will become Fedora 24) has a patched version of Boost 1.59.0 which includes the fix, so putting a workaround in the project might conflict with that patched version of Boost. |
I'm afraid I may have had an unclean environment, in which I tested. With a fresh workspace and merely the proposed changes by @jwakely it compiles just fine. @stefanseefeld Thanks for the advice. I'll remember it for next time. |
@jwakely Thanks for the heads up. How would such an issue be addressed best?
|
Yes, I would add an autoconf / cmake test and only add the missing overload if needed. |
(This is entirely off-topic, but anyhow: Given that "#if BOOST_VERSION == 105900" appears to be the condition under which you'll need this patch, there is really nothing to configure for. Just put the above patch from @jwakely into your source code wherever needed and move on.) |
@jwakely does the patched boost 1.59 version have a difference |
There is no "patched boost 1.59 version". The patch is on master, and will be part of boost 1.60. |
@stefanseefeld I'm quoting @jwakely: "Be aware that Fedora rawhide (which will become Fedora 24) has a patched version of Boost 1.59.0" |
Oh, I stand corrected. Hmm, I don't like that idea. @jwakely, I think rather than having Fedora roll its own Boost.Python release, I think it would be better to try to get a new Boost.Python (bugfix) release out. (As you know, I have been trying to get Boost.Python to the point where I can do releases independently from the rest of Boost, anyhow.) |
Fedora rawhide has a patched Boost 1.59.0 with the same |
@jwakely , that's very unfortunate, in particular as it doesn't allow users to discriminate based on BOOST_VERSION. There should be some way to check for the version using some macro. |
Yes, but it's only needed precisely because of that nightmare we are in. :-( |
If Boost did 1.Y.1 releases more often (including critical fixes like this one and boostorg/log@7da193f) then distros could use that, as it is we have no choice but to ship 1.Y.0 with all the breaking changes that entails, and then patch things to get the distro to build. |
@jwakely, yes, I agree. It's a systemic issue caused by the separation between project maintenance and distro maintenance. (How often have I filed bugs with RH's bugzilla only to be told that this is an "upstream" issue that can't be fixed by RH. As an end-user I don't want to have to care for "upstream"...) Anyhow, sorry for the ranting. I can fully understand and appreciate all the sides of this, as I have been part of this game for a long time... :-) |
Understood. For the next Boost release I plan to try rebuilding everything in Fedora with the release candidates, and try to report regressions before the release, but that is a lot of work and didn't happen this time. |
Here's a little CMake snippet I'll use in order to check for this issue and
|
Thanks for the insightful conversation and the helpful comments about the issue at hand. I look forward to Boost 1.60.0 or the next Boost.Python release, whichever comes first 😝 |
@afh Note that you also need |
Fixes build with boost-1.59. Disable boost-python. See, for example, boostorg/python#39 Signed-off-by: David Spencer <baildon.research@googlemail.com> Signed-off-by: Willy Sudiarto Raharjo <willysr@slackbuilds.org>
Disable boost-python. See, for example, boostorg/python#39 Signed-off-by: David Spencer <baildon.research@googlemail.com> Signed-off-by: Willy Sudiarto Raharjo <willysr@slackbuilds.org>
Fixes build with boost-1.59. Disable boost-python. See, for example, boostorg/python#39 Signed-off-by: David Spencer <baildon.research@googlemail.com> Signed-off-by: Willy Sudiarto Raharjo <willysr@slackbuilds.org>
Disable boost-python. See, for example, boostorg/python#39 Signed-off-by: David Spencer <baildon.research@googlemail.com> Signed-off-by: Willy Sudiarto Raharjo <willysr@slackbuilds.org>
(with minor modification from Jim Bosch)
(with minor modification from Jim Bosch)
This trivial example, similar to the examples in the Boost.Python documentation, compiled with 1.58 but doesn't with 1.59 (using various versions of GCC and Clang):
The relevant error is:
/usr/local/boost-1.59.0/include/boost/python/data_members.hpp:303:15: note: candidate: boost::python::api::object boost::python::make_setter(D&) [with D = int X::*] <near match>
/usr/local/boost-1.59.0/include/boost/python/data_members.hpp:303:15: note: conversion of argument 1 would be ill-formed:
prog.cc:7:37: error: invalid initialization of non-const reference of type 'int X::*&' from an rvalue of type 'int X::*'
The text was updated successfully, but these errors were encountered: