[gentoo-dev] latest boost vs. eselected boost
Hello, a user submitted a bug[1] that cmake always select the latest boost. We the kde team as cmake maintainer found a solution to respect the (e)selected boost. The patched version is not in tree yet, because after my blog post[2] about this issue a discussion in the bug starts. Summary of the comments: 1) Ebuilds should always pick the latest boost version. 2) Boost should be compared to gcc, python, ruby etc So please state your opinion here, before the bug comments explode. In the case that eselect feature for boost will be last rited as in comment 16[1] announced, then you can forget this mail. [1] https://bugs.gentoo.org/show_bug.cgi?id=335108 [2] http://blogs.gentoo.org/johu/2012/01/13/cmake-picks-always-the-latest- boost/ Greetings -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID F3CFD2BD signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] latest boost vs. eselected boost
On 1/19/12 9:05 AM, Johannes Huber wrote: Summary of the comments: 1) Ebuilds should always pick the latest boost version. 2) Boost should be compared to gcc, python, ruby etc [1] https://bugs.gentoo.org/show_bug.cgi?id=335108 Right, Tiziano Müller's (dev-zero) comments are pretty clear that ebuilds should use latest boost. I'm fine with last-riting eselect-boost, and I'm also fine with eselect-boost applying to ebuilds too, like eselect-python. What I mostly care about is consistency and principle of least surprise. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] latest boost vs. eselected boost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/01/12 03:27 AM, Paweł Hajdan, Jr. wrote: On 1/19/12 9:05 AM, Johannes Huber wrote: Summary of the comments: 1) Ebuilds should always pick the latest boost version. 2) Boost should be compared to gcc, python, ruby etc [1] https://bugs.gentoo.org/show_bug.cgi?id=335108 Right, Tiziano Müller's (dev-zero) comments are pretty clear that ebuilds should use latest boost. I'm fine with last-riting eselect-boost, and I'm also fine with eselect-boost applying to ebuilds too, like eselect-python. What I mostly care about is consistency and principle of least surprise. I thought there was a push to eventually de-slot boost? (in which case this issue just disappears) Anyways, if we ARE going to keep boost slotted, we should probably have a mechanism within ebuilds to select the boost version that will be used -- simiar to/same as python and ruby (or perhaps closer to autotools? unsure which paradigm best fits). Yes, I know how much of a potential mess this could be and how much of a PITA it's going to be to do.* I'm not sure if using eselect-boost for this would be a good idea, though; isn't eselect mainly just for the system? IE, when a user is using boost for their own stuffs? * Given that python and ruby already need to do this, maybe it would be a good idea to make an eclass and set of functions that generalize this capability, and then convert the python and ruby eclasses and ebuild to use (or at least inherit) the generalized eclass? Seems better than reinventing the wheel for every slotted build platform.. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk8YSecACgkQAJxUfCtlWe0mpwD/TClHGn/93VFTiuP7S7ZUnF5k yDbm8jRbG2fL0vwiemgBAJ4uYSpFVuzAJgR/ZoDou94umBLarPdc2OxInnH/1QyY =pzBv -END PGP SIGNATURE-
Re: [gentoo-dev] latest boost vs. eselected boost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 19 Jan 2012 11:50:47 -0500 Ian Stakenvicius a...@gentoo.org wrote: I thought there was a push to eventually de-slot boost? (in which case this issue just disappears) Boost doesn't have any ABI stability. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk8YU1sACgkQ96zL6DUtXhHsuwCgk3TfhqnKMwgkKdcSptePpZOT ohsAoIYkkO4EBbHJ7dSwjsGzOjsGXtha =snkX -END PGP SIGNATURE-
Re: [gentoo-dev] latest boost vs. eselected boost
Am Donnerstag, den 19.01.2012, 11:50 -0500 schrieb Ian Stakenvicius:
On 19/01/12 03:27 AM, Paweł Hajdan, Jr. wrote:
On 1/19/12 9:05 AM, Johannes Huber wrote:
Summary of the comments: 1) Ebuilds should always pick the latest
boost version. 2) Boost should be compared to gcc, python, ruby
etc
[1] https://bugs.gentoo.org/show_bug.cgi?id=335108
Right, Tiziano Müller's (dev-zero) comments are pretty clear that
ebuilds should use latest boost.
I'm fine with last-riting eselect-boost, and I'm also fine with
eselect-boost applying to ebuilds too, like eselect-python.
What I mostly care about is consistency and principle of least
surprise.
I thought there was a push to eventually de-slot boost? (in which
case this issue just disappears)
No.
Anyways, if we ARE going to keep boost slotted, we should probably
have a mechanism within ebuilds to select the boost version that will
be used -- simiar to/same as python and ruby (or perhaps closer to
autotools? unsure which paradigm best fits). Yes, I know how much of
a potential mess this could be and how much of a PITA it's going to be
to do.* I'm not sure if using eselect-boost for this would be a good
idea, though; isn't eselect mainly just for the system? IE, when a
user is using boost for their own stuffs?
Yes, exactly. As I wrote in the bug: the eselect-boost module was for
the transition from unslotted to slotted boost as well as for people
doing development on Gentoo using boost.
If you want compare the boost-case to something, it's probably best
compared to sys-libs/db.
Two years ago (maybe there is a better solution by now) I used something
like this to extract the boost-include directory in an ebuild:
BOOST_PKG=$(best_version =dev-libs/boost-1.35.0-r5)
BOOST_VER=$(get_version_component_range 1-2 ${BOOST_PKG/*boost-/})
BOOST_INC=/usr/include/boost-$(replace_all_version_separators _
${BOOST_VER})
Maybe someone can come up with a wrapper to have something like this:
WORKING_BOOST_SLOTS=1.37 1.38 1.42 1.45
[...]
DEPEND=$(slot_deps dev-libs/boost ${WORKING_BOOST_SLOTS})
[...]
BOOST_SLOT=$(best_slot dev-libs/boost ${WORKING_BOOST_SLOTS})
BOOST_INC=$(best_slot_boost_include ${WORKING_BOOST_SLOTS})
which could be used for other slotted libs, like sys-libs/db.
(basically a generalization of the db-use.eclass)
Cheers,
Tiziano
smime.p7s
Description: S/MIME cryptographic signature
