From: "André Draszik" <git@andred.net>
To: "Huang, Jie (Jackie)" <Jackie.Huang@windriver.com>,
"openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 2/2 v2] boost: add support for additional boost libs
Date: Tue, 27 Sep 2016 09:08:45 +0100 [thread overview]
Message-ID: <1474963725.666.7.camel@andred.net> (raw)
In-Reply-To: <1B858668EC6A94408DCA5225FDFA85AA013A2E03AC@ALA-MBA.corp.ad.wrs.com>
On Di, 2016-09-27 at 02:26 +0000, Huang, Jie (Jackie) wrote:
>
> >
> > -----Original Message-----
> > From: André Draszik [mailto:git@andred.net]
> > Sent: Monday, September 26, 2016 4:54 PM
> > To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] [PATCH 2/2 v2] boost: add support for additional
> > boost libs
> >
> > On Mo, 2016-09-26 at 15:56 +0800, jackie.huang@windriver.com wrote:
> > >
> > > From: Jackie Huang <jackie.huang@windriver.com>
> > >
> > > * Added libs:
> > > - container
> > > - context
> > > - coroutine
> > > - exception
> > > - graph_parallel
> > > - locale
> > > - math
> > > - mpi
> > > - wave
> > >
> > > * Add PACKAGECONFIG to add proper dependencies for:
> > > graph_parallel, locale, and mpi.
> > >
> > > * boost-mpi depends on mpich which is in meta-oe,
> > > and boost-graph_parallel depends on boost-mpi,
> > > so they are disabled by default, but can be enabled
> > > in a distro that needs them.
> > >
> > > * context and coroutine are added only for x86 and powerpc.
> > >
> > > Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
> > > ---
> > > meta/recipes-support/boost/boost.inc | 33
> > > ++++++++++++++++++++++++++++++-
> > > --
> > > 1 file changed, 30 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/meta/recipes-support/boost/boost.inc b/meta/recipes-
> > > support/boost/boost.inc
> > > index 5696b6a..7637a4e 100644
> > > --- a/meta/recipes-support/boost/boost.inc
> > > +++ b/meta/recipes-support/boost/boost.inc
> > > @@ -8,11 +8,14 @@ ARM_INSTRUCTION_SET_armv5 = "arm"
> > > BOOST_LIBS = "\
> > > atomic \
> > > chrono \
> > > + container \
> > > date_time \
> > > + exception \
> > > filesystem \
> > > graph \
> > > iostreams \
> > > log \
> > > + math \
> > > program_options \
> > > random \
> > > regex \
> > > @@ -22,12 +25,28 @@ BOOST_LIBS = "\
> > > timer \
> > > test \
> > > thread \
> > > + wave \
> > > "
> > >
> > > -# optional boost-python library
> > > -PACKAGECONFIG ??= ""
> > > +# only supported by x86 and powerpc
> > > +BOOST_LIBS_append_x86 = " context coroutine"
> > > +BOOST_LIBS_append_x86-64 = " context coroutine"
> > > +BOOST_LIBS_append_powerpc = " context coroutine"
> > > +
> > > +# optional libraries
> > > +PACKAGECONFIG ??= "locale"
> > > +PACKAGECONFIG[locale] = ",,icu"
> > > +PACKAGECONFIG[graph_parallel] = ",,,boost-mpi mpich"
> > > +PACKAGECONFIG[mpi] = ",,mpich"
> > > PACKAGECONFIG[python] = ",,python python3"
> > > -BOOST_LIBS += "${@bb.utils.contains('PACKAGECONFIG', 'python',
> > > 'python
> > > python3', '', d)}"
> > > +
> > > +BOOST_LIBS += "\
> > > + ${@bb.utils.contains('PACKAGECONFIG', 'locale', 'locale', '', d)}
> > > \
> > > + ${@bb.utils.contains('PACKAGECONFIG', 'graph_parallel',
> > > 'graph_parallel mpi', \
> > > + bb.utils.contains('PACKAGECONFIG', 'mpi',
> > > 'mpi',
> > > '', d), d)} \
> > > + ${@bb.utils.contains('PACKAGECONFIG', 'python', 'python python3',
> > > '',
> > > d)} \
> > > +"
> >
> > Rather than having two ways to define what packages to build,
> > PACKAGECONFIG
> > and BOOST_LIBS, where each of them only supports a different subset of
>
> I'm not a fan of this way, I just keep using the way it was.
>
> >
> > boost's libraries, can we just have one, PACKAGECONFIG, and have it
> > support
> > all of the potential libraries?
>
> Yes, I think it's possible, but it will most likely end up with many empty
> PACKAGECONFIG definitions like:
> PACKAGECONFIG[atomic] = ",,,"
> PACKAGECONFIG[chrono] = ",,,"
> PACKAGECONFIG[container] = ",,,"
> PACKAGECONFIG[date_time] = ",,,"
> PACKAGECONFIG[exception] = ",,,"
>
> If you think it's a better way and no other objection, I think I will do
> that in a
> separate commit as follow-up.
I don't think you'd need empty PACKAGECONFIG[flag] definitions, see
base.bbclass.
Cheers,
Andre'
next prev parent reply other threads:[~2016-09-27 8:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-26 7:56 [PATCH 0/2 v2] boost: add support for additional boost libs jackie.huang
2016-09-26 7:56 ` [PATCH 1/2 v2] boost: disable pch when build boost-math jackie.huang
2016-09-26 7:56 ` [PATCH 2/2 v2] boost: add support for additional boost libs jackie.huang
2016-09-26 8:53 ` André Draszik
2016-09-27 2:26 ` Huang, Jie (Jackie)
2016-09-27 8:08 ` André Draszik [this message]
2016-09-27 8:22 ` Huang, Jie (Jackie)
2016-09-27 9:13 ` André Draszik
2016-09-27 12:28 ` Burton, Ross
2016-09-28 0:43 ` Huang, Jie (Jackie)
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=1474963725.666.7.camel@andred.net \
--to=git@andred.net \
--cc=Jackie.Huang@windriver.com \
--cc=openembedded-core@lists.openembedded.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