Re: [yocto] State of Meson build system through eSDK

On 8/13/19 12:59 PM, Alexander Kanavin wrote: On Tue, 13 Aug 2019 at 12:41, Martin Siegumfeldt mailto:m...@gomspace.com>> wrote: The link above is not about eSDK, it's about devtool which works perfectly fine in a non-SDK environment (e.g. plain yocto). Hmm, since it is a subsect

Re: [yocto] State of Meson build system through eSDK

On 8/13/19 11:57 AM, Alexander Kanavin wrote: On Tue, 13 Aug 2019 at 10:40, Martin Siegumfeldt mailto:m...@gomspace.com>> wrote: I am wondering if/when Meson is expected supported through the eSDK - I don't see it from the list: https://www.yoctoproject.org/docs/current/sdk-manual/sdk-

[yocto] State of Meson build system through eSDK

Hi, I am wondering if/when Meson is expected supported through the eSDK - I don't see it from the list: https://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html#sdk-a-closer-look-at-devtool-add ? Thanks, Martin -- ___ yocto mailing list

Re: [yocto] Sequential generation of eSDK from with the same workspace fails for similar machines

Hi Chen, You are right, simply renaming 'SDK_NAME' solves the issue. Thanks, Martin From: ChenQi Sent: Wednesday, August 29, 2018 3:36:41 AM To: Martin Siegumfeldt; yocto@yoctoproject.org Subject: Re: [yocto] Sequential generation of eSDK fro

[yocto] Sequential generation of eSDK from with the same workspace fails for similar machines

Hi, I am subsequently trying to render eSDKs for two different machines from within the same workspace. The first (succeeding) is built according to 'MACHINE="zcu102-zynqmp" bitbake core-image-minimal -c populate_sdk_ext' whereas the second (MACHINE="zcu104-zynqmp" bitbake core-image-minimal -

Re: [yocto] Recipe availability through eSDK (cppzmq)

dding 'IMAGE_INSTALL += "cppzmq-dev"' to local.conf. On the variables passed in from the shell, can you refer to the location of this whitelist - for future reference? Thanks for your support - highly appreciated. Martin From: Andrea Galbusera Sent: Wednesday, May 2, 201

Re: [yocto] Recipe availability through eSDK (cppzmq)

d and the image generation does not pick up the ${PN}-dev variant. In essence, it looks like image generation disregards recipes residing exclusively in the ${PN}-dev variant - question is whether this is intended or not? Br, Martin ________ From: Martin Siegumfeldt

Re: [yocto] Recipe availability through eSDK (cppzmq)

Hi Andrea, From: Andrea Galbusera Sent: Tuesday, May 1, 2018 16:06 To: Martin Siegumfeldt Cc: yocto@yoctoproject.org Subject: Re: [yocto] Recipe availability through eSDK (cppzmq) Hi Martin, On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt wrote: >

[yocto] Recipe availability through eSDK (cppzmq)

Hi, I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The search function does not return anything, despite the recipe being available through local recipe: martin@dell:~/gomspace_sdk$ ls layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/ cppzmq_git.bb files zero

Re: [yocto] Extensible SDK and DEFAULT_PREFERENCE

On Wed, Apr 18, 2018 at 5:41 AM, Martin Siegumfeldt wrote: > Hi, > > I am having a number of recipes residing in two versions, some (development > versions) being down-prioritized using: > > DEFAULT_PREFERENCE = "-1" > > > The source code is hosted at

[yocto] Extensible SDK and DEFAULT_PREFERENCE

Hi, I am having a number of recipes residing in two versions, some (development versions) being down-prioritized using: DEFAULT_PREFERENCE = "-1" The source code is hosted at a private git repository, and the git version is selected using 'AUTOREV'. The extensible SDK renders successfully, ho

Re: [yocto] Exposure of Shared Library Functionality through eSDK - missing include file

After a bit of further study, it turns out that adding the explicit dependency to the recipe: DEPENDS = "libisl" resolves the issue. Br, Martin ____ From: Martin Siegumfeldt Sent: Tuesday, February 13, 2018 2:10:48 PM To: yocto@yoctoproject.o

[yocto] Exposure of Shared Library Functionality through eSDK - missing include file

Hi, We are implementing certain logic within a shared library and aims at exposing this through the extensible SDK, unfortunately without success so far. The library and it's associated header file is successfully added to the image and appears also present from the eSDK: martin@dell:~/gomspac

Re: [yocto] wic- optimizing an image containing a large empty partition

condition is present Done! I'll look into your above proposal - I wonder if fastboot is capable of this without further effort? Thanks, Martin From: Ed Bartosh Sent: Tuesday, January 16, 2018 10:58 To: Martin Siegumfeldt Cc: yocto@yoctoproject.org Subject: Re: [yocto] wic- optimizing an

[yocto] wic- optimizing an image containing a large empty partition

Hi, I am trying to optimize an image having a fairly large empty partition with regards to file size - wks file: martin@martin-Precision-5510:~/work/z7000-distro_wic/meta-z7000$ cat scripts/lib/wic/canned-wks/gs-boot-rootfs.wks part --ondisk mmcblk --size 4 part /boot --source bootimg-partiti

Re: [yocto] Issues building Extensible SDK

5:29 AM To: Martin Siegumfeldt; yocto@yoctoproject.org Subject: Re: [yocto] Issues building Extensible SDK Hi Martin, Try: $ bitbake -e | grep '^INHERIT=.*uninative' If there is nothing, then add the following line to conf/local.conf: INHERIT += "uninative" // Robert