Gentoo Archives: gentoo-dev

From: Ian Stakenvicius <axs@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
Date: Tue, 28 Aug 2012 14:48:50
Message-Id: 503CD9A7.2050707@gentoo.org
In Reply to: Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost. by "Michał Górny"
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA256
3
4 On 28/08/12 10:43 AM, Michał Górny wrote:
5 > On Tue, 28 Aug 2012 10:10:01 +0200 Tiziano Müller
6 > <dev-zero@g.o> wrote:
7 >
8 >> Am Dienstag, den 28.08.2012, 10:06 +0200 schrieb Michał Górny:
9 >>> On Tue, 28 Aug 2012 06:26:02 +0200 Arfrever Frehtes Taifersar
10 >>> Arahesis <arfrever.fta@×××××.com> wrote:
11 >>>
12 >>>> 2012-08-28 00:19:28 Michał Górny napisał(a):
13 >>>>> --- /dev/null +++ b/gx86/eclass/boost-utils.eclass @@ -0,0
14 >>>>> +1,43 @@ +# Copyright 1999-2012 Gentoo Foundation +#
15 >>>>> Distributed under the terms of the GNU General Public
16 >>>>> License v2 +# $Header: $ + +if [[ ! ${_BOOST_ECLASS} ]];
17 >>>>> then + +# @ECLASS: boost-utils.eclass +# @MAINTAINER: +#
18 >>>>> mgorny@g.o
19 >>>>
20 >>>> It is better to copy list of maintainers from
21 >>>> gentoo-x86/dev-libs/boost/metadata.xml.
22 >>>>
23 >>>>> +# @BLURB: helper functions for packages using Boost C++
24 >>>>> library +# @DESCRIPTION: +# Helper functions to be used
25 >>>>> when building packages using the Boost C++ +# library
26 >>>>> collection. + +case ${EAPI:-0} in + 0|1|2|3|4) ;; + *) die
27 >>>>> "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
28 >>>>> +esac
29 >>>>
30 >>>> Please accept all EAPIs.
31 >>>
32 >>> These are EAPIs which are allowed throughout the tree, sorry.
33 >>> Feel free to ping Council about adding non-standard EAPIs to
34 >>> eclasses.
35 >>>
36 >>>>> +inherit versionator + +# @FUNCTION:
37 >>>>> boost-utils_get_best_slot +# @DESCRIPTION: +# Get newest
38 >>>>> SLOT (major version) of Boost. +boost-utils_get_best_slot()
39 >>>>> { + local pkg=dev-libs/boost + local atom=$(best_version
40 >>>>> ${pkg}) + get_version_component_range 1-2 ${atom#${pkg}}
41 >>>>> +} + +# @FUNCTION: boost-utils_get_includedir +#
42 >>>>> @DESCRIPTION: +# Get correct includedir for best Boost
43 >>>>> version. Outputs the sole path +# (without -I).
44 >>>>> +boost-utils_get_includedir() { + local
45 >>>>> slot=$(boost-utils_get_best_slot) + has "${EAPI:-0}" 0 1 2
46 >>>>> && ! use prefix && EPREFIX= + + echo -n
47 >>>>> "${EPREFIX}/usr/include/boost-${slot/./_}" +}
48 >>>>
49 >>>> There needs to be a way to specify maximal accepted slot of
50 >>>> Boost. Examples of some possibilities: *
51 >>>> BOOST_MAX_SLOT="1.49" global variable * '--max 1.49'
52 >>>> arguments for boost-utils_get_* functions
53 >>>
54 >>> I'd rather wait with that till Tiziano expresses his opinion.
55 >>> I think the policy ought to be 'always prefer newest version'
56 >>> but I guess that's hard with boost.
57 >>>
58 >>
59 >> one of the points of having a slotted boost (besides solving the
60 >> rebuild when API/ABI breakages occur) is that a package may also
61 >> use an older boost slot (currently it only would make sense if
62 >> we'd backport the glibc-2.16 patches but that's a different
63 >> story). So I'd prefer if we'd have a BOOST_MAX_SLOT variable.
64 >
65 > Do we want to support using random old versions of boost then or
66 > just the newest supported SLOT? If the latter, we could get away
67 > without using best_version, and just request devs to depend on
68 > specific boost slot then.
69 >
70
71 IIRC from comments on IRC, the idea with boost is that "newest
72 available" is what is recommended to be used, but obviously "newest
73 supported by ebuild" would take precedence, if a package can't be
74 built against a newer boost.
75
76 Otherwise why would we bother to slot in the first place?
77
78 -----BEGIN PGP SIGNATURE-----
79 Version: GnuPG v2.0.19 (GNU/Linux)
80
81 iF4EAREIAAYFAlA82acACgkQ2ugaI38ACPAc0gD+Ohokg0d6MAikZfLsyenyBnb6
82 PMIRVUI3VtHXcOz1cG4BALV9qTK1qSSUnNenRjjJxktdZ0f1Jatb69R+x9JXVM2m
83 =cIfW
84 -----END PGP SIGNATURE-----

Replies