Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.

[Michał Górny]

On Tue, 28 Aug 2012 10:45:59 -0400
Ian Stakenvicius <axs@g.o> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 28/08/12 10:43 AM, Michał Górny wrote:
> > On Tue, 28 Aug 2012 10:10:01 +0200 Tiziano Müller
> > <dev-zero@g.o> wrote:
> >
> >> Am Dienstag, den 28.08.2012, 10:06 +0200 schrieb Michał Górny:
> >>> On Tue, 28 Aug 2012 06:26:02 +0200 Arfrever Frehtes Taifersar
> >>> Arahesis <arfrever.fta@×××××.com> wrote:
> >>>
> >>>> 2012-08-28 00:19:28 Michał Górny napisał(a):
> >>>>> --- /dev/null +++ b/gx86/eclass/boost-utils.eclass @@ -0,0
> >>>>> +1,43 @@ +# Copyright 1999-2012 Gentoo Foundation +#
> >>>>> Distributed under the terms of the GNU General Public
> >>>>> License v2 +# $Header: $ + +if [[ ! ${_BOOST_ECLASS} ]];
> >>>>> then + +# @ECLASS: boost-utils.eclass +# @MAINTAINER: +#
> >>>>> mgorny@g.o
> >>>>
> >>>> It is better to copy list of maintainers from
> >>>> gentoo-x86/dev-libs/boost/metadata.xml.
> >>>>
> >>>>> +# @BLURB: helper functions for packages using Boost C++
> >>>>> library +# @DESCRIPTION: +# Helper functions to be used
> >>>>> when building packages using the Boost C++ +# library
> >>>>> collection. + +case ${EAPI:-0} in +	0|1|2|3|4) ;;
> >>>>> +	*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> >>>>> established." +esac
> >>>>
> >>>> Please accept all EAPIs.
> >>>
> >>> These are EAPIs which are allowed throughout the tree, sorry.
> >>> Feel free to ping Council about adding non-standard EAPIs to
> >>> eclasses.
> >>>
> >>>>> +inherit versionator + +# @FUNCTION:
> >>>>> boost-utils_get_best_slot +# @DESCRIPTION: +# Get newest
> >>>>> SLOT (major version) of Boost. +boost-utils_get_best_slot()
> >>>>> { +	local pkg=dev-libs/boost +	local
> >>>>> atom=$(best_version ${pkg}) +
> >>>>> get_version_component_range 1-2 ${atom#${pkg}} +} + +#
> >>>>> @FUNCTION: boost-utils_get_includedir +# @DESCRIPTION: +# Get
> >>>>> correct includedir for best Boost version. Outputs the sole
> >>>>> path +# (without -I). +boost-utils_get_includedir() { +
> >>>>> local slot=$(boost-utils_get_best_slot) +	has
> >>>>> "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX= + +	echo
> >>>>> -n "${EPREFIX}/usr/include/boost-${slot/./_}" +}
> >>>>
> >>>> There needs to be a way to specify maximal accepted slot of
> >>>> Boost. Examples of some possibilities: *
> >>>> BOOST_MAX_SLOT="1.49" global variable * '--max 1.49'
> >>>> arguments for boost-utils_get_* functions
> >>>
> >>> I'd rather wait with that till Tiziano expresses his opinion.
> >>> I think the policy ought to be 'always prefer newest version'
> >>> but I guess that's hard with boost.
> >>>
> >>
> >> one of the points of having a slotted boost (besides solving the
> >> rebuild when API/ABI breakages occur) is that a package may also
> >> use an older boost slot (currently it only would make sense if
> >> we'd backport the glibc-2.16 patches but that's a different
> >> story). So I'd prefer if we'd have a BOOST_MAX_SLOT variable.
> >
> > Do we want to support using random old versions of boost then or
> > just the newest supported SLOT? If the latter, we could get away
> > without using best_version, and just request devs to depend on
> > specific boost slot then.
> >
>
> IIRC from comments on IRC, the idea with boost is that "newest
> available" is what is recommended to be used, but obviously "newest
> supported by ebuild" would take precedence, if a package can't be
> built against a newer boost.
>
> Otherwise why would we bother to slot in the first place?

I meant 'require only newest slot supported by package' vs 'any older
slot would work'.

-- 
Best regards,
Michał Górny