public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Tiziano Müller" <dev-zero@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Lastrite: app-admin/eselect-boost & Boost plans
Date: Fri, 24 Aug 2012 11:50:11 +0200	[thread overview]
Message-ID: <1345801811.68322.26.camel@storm> (raw)

Some of you may have already noticed, that boost >=1.50.0-r1 does not
pull in eselect-boost anymore and does not install a profile for it
either. This is on purpose since app-admin/eselect-boost will be
removed.

Why: the purpose of eselect-boost was to make the introduction of
slotted-boost easier (since we wouldn't have to fix all packages at
once) and to help people using Gentoo as a development platform.
It was never the intention that Ebuilds should depend permanently on the
symlinks created by eselect-boost depending on a users selection.
Especially with EAPI-5 slot-operators the PM must be able to assume that
a package depending on boost links/uses the best version of boost
according to its dependency specification.

I apologize for not having made that clear earlier.

How to make sure your package uses latest boost (if it doesn't detect it
properly)? I'm using something like this in my ebuilds which require
boost:

    BOOST_PKG="$(best_version ">=dev-libs/boost-1.40.0")"
    BOOST_VER="$(get_version_component_range 1-2 "${BOOST_PKG/*boost-/}")"
    BOOST_VER="$(replace_all_version_separators _ "${BOOST_VER}")"
    BOOST_INC="/usr/include/boost-${BOOST_VER}"

If someone has a better idea (possibly introduce pkg-config files for
boost) and/or write/extend an eclass to handle such cases (probably
similar to the db-use.eclass) I'd appreciate a helping hand.

Further plans:

When unmasking glibc-2.16, most of the old boost versions will be broken
and old unstable boost-versions must be removed.
As soon as glibc-2.16 gets stable, boost-1.50.0 has to be stabilized and
old stable versions of boost must be removed.

Boost-1.51.0: mgorny (thanks a lot, btw) and I are working on splitted
ebuilds. The wishlist also includes switching to the cmake-based
modularized boost distribution which would make the ebuilds a lot
easier. It would also reduce the required disk-space when building and
testing.
Since 1.51 got released already, we may decide to introduce this in 1.52
and release 1.51 as usual.

At this point I'd also like to thank hwoarang, floppym and Arfrever for
their help in maintaining boost... and of course everyone participating
in testing, bug-fixing and stabilizing that beast.

Ideas? Hints? Comments?

Cheers,
Tiziano






                 reply	other threads:[~2012-08-24  9:51 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1345801811.68322.26.camel@storm \
    --to=dev-zero@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox