FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 01-19-2012, 07:05 AM
Johannes Huber
 
Default 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
 
Old 01-19-2012, 07:27 AM
"Paweł Hajdan, Jr."
 
Default 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.
 
Old 01-19-2012, 03:50 PM
Ian Stakenvicius
 
Default 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-----
 
Old 01-19-2012, 04:31 PM
Ciaran McCreesh
 
Default latest boost vs. eselected boost

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 19 Jan 2012 11:50:47 -0500
Ian Stakenvicius <axs@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)

iEYEARECAAYFAk8YU1sACgkQ96zL6DUtXhHsuwCgk3TfhqnKMw gkKdcSptePpZOT
ohsAoIYkkO4EBbHJ7dSwjsGzOjsGXtha
=snkX
-----END PGP SIGNATURE-----
 
Old 01-20-2012, 05:22 AM
Tiziano Müller
 
Default 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
 

Thread Tools




All times are GMT. The time now is 03:42 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org