[oe] [PATCH 1/2] protobuf: add protobuf-c recipe

Bruce Ashfield bruce.ashfield at gmail.com
Wed Apr 20 14:32:58 UTC 2016


On Wed, Apr 20, 2016 at 4:32 AM, Felipe Ferreri Tonello <
eu at felipetonello.com> wrote:

> Hi Bruce,
>
> On 19/04/16 20:55, Bruce Ashfield wrote:
> > On Tue, Apr 19, 2016 at 3:46 PM, Bruce Ashfield <
> bruce.ashfield at gmail.com>
> > wrote:
> >
> >>
> >>
> >> On Tue, Apr 19, 2016 at 11:40 AM, Felipe F. Tonello <
> eu at felipetonello.com>
> >> wrote:
> >>
> >>> Initial version of recipe. The main package could be split into two to
> >>> separate the compiler. This also applies to protobuf recipe.
> >>>
> >>>
> >> More precisely, this is the initial version outside of
> meta-virtualization
> >> which enea added
> >> in 2012 :) It was added as a dependency for criu (hence why it was put
> in
> >> meta-virt).
> >>
> >> If we move it to meta-oe, we at least owe that other implementation a
> >> reference in the commit.
> >>
> >>
> > s/if/when/.
> >
> > I'm happy to purge all the protobuf* recipes from meta-virt, since they
> > were only there as
> > support mechanisms (and I wasn't involved in their original merge).
> >
> > But if you can take a look at what's in the meta-virt recipe, I'll do
> some
> > runtime testing with your
> > variant here, and drop the meta-virt ones when I can confirm criu works.
> >
>
> Regular protobuf recipe is already part of meta-oe. That's why I added
> this one there too.
>

Sure. That's obvious from the layer index, as is the existence of the one
in meta-virt.

Credit, where credit is due. It's not my work, so I'm not asking for any
credit,
but simply duplicating something that already exists without a nod to the
older one
isn't ideal.

All I was asking was that if you could a link to the meta-virt one in the
commit header
so that someone not familiar with the layer index can see the two options
.. and
at the same time I was wondering if you'd seen the meta-virt one and did
this one
differently for technical reasons. That makes it easier for me to drop
recipes as they
get cloned around to new (and better) locations.

Bruce


> > Cheers,
> >
> > Bruce
> >
> >
> >> Did you check the version we have there for deltas ? There are
> differences
> >> in the recipe, and
> >> it would be good to know if you've looked and determined they aren't
> >> necessary.
> >>
> >> Cheers,
> >>
> >> Bruce
> >>
> >>
> >>> Signed-off-by: Felipe F. Tonello <eu at felipetonello.com>
> >>> ---
> >>>  .../recipes-devtools/protobuf/protobuf-c_1.2.1.bb  | 26
> >>> ++++++++++++++++++++++
> >>>  1 file changed, 26 insertions(+)
> >>>  create mode 100644 meta-oe/recipes-devtools/protobuf/
> protobuf-c_1.2.1.bb
> >>>
> >>> diff --git a/meta-oe/recipes-devtools/protobuf/protobuf-c_1.2.1.bb
> >>> b/meta-oe/recipes-devtools/protobuf/protobuf-c_1.2.1.bb
> >>> new file mode 100644
> >>> index 000000000000..88cdb0bccd8e
> >>> --- /dev/null
> >>> +++ b/meta-oe/recipes-devtools/protobuf/protobuf-c_1.2.1.bb
> >>> @@ -0,0 +1,26 @@
> >>> +SUMMARY = "Protocol Buffers - structured data serialisation mechanism"
> >>> +DESCRIPTION = "This is protobuf-c, a C implementation of the Google
> >>> Protocol Buffers data \
> >>> +serialization format. It includes libprotobuf-c, a pure C library
> that \
> >>> +implements protobuf encoding and decoding, and protoc-c, a code
> >>> generator that \
> >>> +converts Protocol Buffer .proto files to C descriptor code, based on
> the
> >>> \
> >>> +original protoc. protobuf-c formerly included an RPC implementation;
> >>> that code \
> >>> +has been split out into the protobuf-c-rpc project."
> >>> +HOMEPAGE = "https://github.com/protobuf-c/protobuf-c"
> >>> +SECTION = "console/tools"
> >>> +LICENSE = "BSD-2-Clause"
> >>> +
> >>> +DEPENDS = "protobuf-native protobuf"
> >>> +
> >>> +PACKAGE_BEFORE_PN = "${PN}-compiler"
> >>> +
> >>> +LIC_FILES_CHKSUM =
> "file://LICENSE;md5=235c3195a3968524dc1524b4ebea0c0e"
> >>> +SRC_URI = "
> >>> https://github.com/protobuf-c/protobuf-c/archive/v${PV}.tar.gz"
> >>> +
> >>> +SRC_URI[md5sum] = "b884aeba4283309445a8e3b6e7322dd6"
> >>> +SRC_URI[sha256sum] =
> >>> "2d708fb3c024b9e6e86df141faff802194f5db90a4b79e6d4aa6bd61dd983dd6"
> >>> +
> >>> +inherit autotools pkgconfig
> >>> +
> >>> +FILES_${PN}-compiler = "${bindir}"
> >>> +
> >>> +BBCLASSEXTEND = "native nativesdk"
> >>> --
> >>> 2.8.0
> >>>
> >>> --
>
> Felipe
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"



More information about the Openembedded-devel mailing list