[yocto] Yocto and Google protobuffer

[Pietro]

Maciej Borzęcki
<maciej.borzecki at rndity.com> writes:

> On Thu, Sep 1, 2016 at 5:45 PM, Pietro <pulsarpietro at posteo.net> wrote:
>> Herman van Hazendonk <me at herrie.org>
>> writes:
>>
>>> If it takes the wrong version, it could be your layers aren't in the
>>> right order. That's the first thing to check.
>>>
>>> You might want to try to run bitbake with
>>>
>>> -f protobuf -c cleanall or -f protobuf-native -c cleanall
>>>
>>> This will remove all locally ;)
>>>
>>> Then rebuild it... I haven't played much with the -native bits, so not
>>> sure how those work.
>>>
>> I needed to specify DEPENDS = "protobuf-native" to get it working, I
>> would be really interested to understand exactly what that does, but I
>> must admit to myself I can't understand everything in a single shot.
>
> Quoting my first email:
>>> All you need to do,
>>>is include meta-oe in your layers (bblayers.conf) and have
>>> protobuf-native listed in DEPENDS inside your package recipe.
>
> DEPENDS lists build time dependencies, like libraries, tools etc.
> protobuf-native, by convention, means that the package was built for
> your build host. This enables you to run protoc during the build to
> generate proper language bindings.
>
>>
>> So never mind.
>>
>> I still have another question :-)
>>
>> I am about to create another recipe for the gprc library for C++, to
>> build it on my local machine has been pretty simple:
>>
>> $ git clone -b $(curl -L http://grpc.io/release)
>> https://github.com/grpc/grpc
>> $ cd grpc
>> $ git submodule update --init
>> $ make
>> $ [sudo] make install
>>
>> The recipe I have created so far would clone/checkout the source code
>> from a GIT repo or something similar and then the build process could
>> start straight away.
>>
>> In my case I have an additional step:
>>
>> git submodule update --init
>>
>
> There's a submodule fetcher, when setting SRC_URI use `gitsm://`
> instead of `git://` see
> https://www.yoctoproject.org/docs/2.1/bitbake-user-manual/bitbake-user-manual.html#gitsm-fetcher
> for details.
>
> Cheers,
> -- 
> Maciej Borzecki
> RnDity
Thanks a lot.

It looks like the project I am trying to clone does not follow the
convention the gitsm module expects.

ERROR: Function failed: Fetcher failure: Fetch command failed with exit
code 1, output:
cp: cannot stat
'/.../build/downloads/git2/github.com.grpc.grpc/modules': No such file or directory


Is there a way to get around it ?

I have also noticed that the tag parameter does not work properly - it
might be me making a mistake though.

SRC_URI =
"git://github.com/grpc/grpc;protocol=http;rev=3df9bdf88013e4c9cb5b5f092ac7cd1aad11fa96

Works fine, but:

ERROR: Function failed: Fetcher failure for URL:
'git://github.com/grpc/grpc;protocol=http;tag=v1.0.0'. The command git
-c core.fsyncobjectfiles=0 ls-remote http://github.com/grpc/grpc
refs/heads/v1.0.0 refs/t
ags/v1.0.0^{} gave empty output unexpectedly


And indeed the command

git -c core.fsyncobjectfiles=0 ls-remote http://github.com/grpc/grpc
refs/heads/v1.0.0 refs/tags/v1.0.0^{}


Does not result in any output while the command :

git -c core.fsyncobjectfiles=0 ls-remote http://github.com/grpc/grpc
refs/heads/v1.0.0 refs/tags/v1.0.0

Results in :


2a69139aa7f609e439c24a46754252a5f9d37500        refs/tags/v1.0.0

What's the use of '^{}' ?