On Di, 2016-09-27 at 08:22 +0000, Huang, Jie (Jackie) wrote: > > > > > -----Original Message----- > > From: André Draszik [mailto:g...@andred.net] > > Sent: Tuesday, September 27, 2016 4:09 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 Di, 2016-09-27 at 02:26 +0000, Huang, Jie (Jackie) wrote: > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: André Draszik [mailto:g...@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.hu...@windriver.com wrote: > > > > > > > > > > > > > > > From: Jackie Huang <jackie.hu...@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.hu...@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. > > Could you be more specific? > > I think it's needed because I got QA issues without the definitions: > > WARNING: boost-1.61.0-r0 do_configure: QA Issue: boost: invalid > PACKAGECONFIG: atomic [invalid-packageconfig]
OK, you're right. That's from insane.bbclass :-( Cheers, Andre' -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
