[yocto] Bitbake recipe using CMake that requires python-six as part of compiling?

[Giordon Stark]

Yes. The CMakeLists file definitely doesn't install that (annoyingly).
Playing around a bit, I created a test recipe, added these lines in my
open62541.inc file (original recipe here)

do_install_append() {
  install -d ${D}${includedir}
  install -m 644 ${B}/open62541.h ${D}${includedir}
}

FILES_${PN}_append = "${includedir}/open62541.h"

and it looks like the test recipe can pick up that header file correctly.
So I think this is correct-er (at least for code that uses #include
<open62541.h>).

Thanks for all the feedback so far,

Giordon

On Tue, Mar 6, 2018 at 3:00 PM Burton, Ross <ross.burton at intel.com> wrote:

> If the cmakelists file doesn't install that (and it should) then yes
> you'll need to use do_install_append.
>
> Ross
>
> On 6 March 2018 at 20:46, Giordon Stark <kratsg at gmail.com> wrote:
>
>> Great. So when I have this recipe set up -- how do I make sure, or tell
>> other people who write a recipe depending on this -- how to find a header
>> file built by it?
>>
>> Specifically, I see this header file in a (non-standard?) location which
>> is normally linked by others:
>>
>> |  #include <open62541.h>
>>
>> and this header file is at ${B}/open62541.h
>> (tmp/work/aarch64-poky-linux/open62541/0.3-r0/build/open62541.h). Is
>> this something that I just handle with a `do_install_append()` line? The
>> documentation here
>> https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html isn't
>> very clear to me.
>>
>> e.g. for another recipe that just adds "open62541" in it's DEPENDS.
>>
>> Giordon
>>
>> On Tue, Mar 6, 2018 at 2:32 PM Burton, Ross <ross.burton at intel.com>
>> wrote:
>>
>>> On 6 March 2018 at 20:24, Giordon Stark <kratsg at gmail.com> wrote:
>>>
>>>> You can drop the S assignment as that is the default value.
>>>>>
>>>>
>>>> Didn't realize, neat. I knew I needed to set it for `git` clones since
>>>> it always throws it into a ${WORKDIR}/git folder.
>>>>
>>>
>>> Yes, for git clones you need to override it.
>>>
>>>
>>>>
>>>>> Github /archive/ tarballs can and do change over time, which gets very
>>>>> annoying when you need to go and change the checksums.
>>>>>
>>>>
>>>> Really? Dang...
>>>>
>>>
>>> Yeah. :/  Took us ages to verify this happens but it definitely does.
>>>
>>>
>>>> My hunch without reading the upstream CMake files is that they don't
>>>>> support out-of-tree builds.  If it worked from git then that's another
>>>>> reason to switch back.
>>>>>
>>>>
>>>> It seems like this is the case here. I'm ok using git clones for now.
>>>> Thanks.
>>>>
>>>
>>> It *shouldn't* matter here as the /archive/ tarball should have
>>> identical contents to a clone of the same tag, but it's possible that the
>>> build system looks for a .git/ directory and changes how it builds.  That's
>>> kind of stupid but it wouldn't be the first time I've seen it break builds.
>>>
>>> Ross
>>>
>> --
>> Giordon Stark
>>
>
> --
Giordon Stark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180306/f75d47e5/attachment.html>