[OE-core] [meta-clang] oe-core and meta-clang llvm coexsting?

Hi, I'm trying to integrate the meta-clang version of LLVM 4.0 (used for recipes that need a newer LLVM version) alongside the oe-core version of LLVM 3.3 (used for mesa). I'd like some recipes to use LLVM 4.0 and some to use LLVM 3.3 and for them not to collide with each other. Right now,

Re: [OE-core] [meta-clang] oe-core and meta-clang llvm coexsting?

On 03/30/2017 12:31 PM, Khem Raj wrote: On 3/30/17 12:20 PM, Martin Kelly wrote: Hi, I'm trying to integrate the meta-clang version of LLVM 4.0 (used for recipes that need a newer LLVM version) alongside the oe-core version of LLVM 3.3 (used for mesa). I'd like some recipes to use LLVM 4.0

Re: [OE-core] [meta-clang] oe-core and meta-clang llvm coexsting?

On 03/31/2017 01:51 AM, Burton, Ross wrote: On 30 March 2017 at 20:20, Martin Kelly <mke...@xevo.com <mailto:mke...@xevo.com>> wrote: I'm trying to integrate the meta-clang version of LLVM 4.0 (used for recipes that need a newer LLVM version) alongside the oe-core ver

Re: [OE-core] [meta-clang] oe-core and meta-clang llvm coexsting?

On 03/30/2017 04:58 PM, Martin Kelly wrote: On 03/30/2017 12:31 PM, Khem Raj wrote: On 3/30/17 12:20 PM, Martin Kelly wrote: Hi, I'm trying to integrate the meta-clang version of LLVM 4.0 (used for recipes that need a newer LLVM version) alongside the oe-core version of LLVM 3.3 (used

Re: [OE-core] [PATCH] libsdl: enable X11 for nativesdk

On 04/11/2017 10:14 AM, Richard Purdie wrote: On Tue, 2017-04-11 at 09:34 -0700, akuster808 wrote: On 04/06/2017 12:55 PM, Martin Kelly wrote: From: Martin Kelly <mke...@xevo.com> Currently, the following situation fails: - Build an SDK and image. Make the image support gr

[OE-core] [PATCH] libsdl: enable X11 for nativesdk

From: Martin Kelly <mke...@xevo.com> Currently, the following situation fails: - Build an SDK and image. Make the image support graphics but not X11. - Extract SDK and copy image somewhere outside of the Yocto workspace. Do runqemu on the image. This results in the error:

[OE-core] [PATCH] qemu: use python2.7 instead of python2

From: Martin Kelly <mke...@xevo.com> meta/conf/bitbake.conf puts python2.7 into the HOSTTOOLS variable but not python2, so only python2.7 is guaranteed. In addition, on some distros -- such as Amazon Linux -- /usr/bin/python2 doesn't exist but python2.7 does. So, use python2.7 for the --

[OE-core] [meta-oe][PATCH] libsdl: enable X11 for nativesdk

From: Martin Kelly <mke...@xevo.com> Currently, the following situation fails: - Build an SDK and image. Make the image support graphics but not X11. - Extract SDK and copy image somewhere outside of the Yocto workspace. Do runqemu on the image. This results in the error:

Re: [OE-core] [meta-clang] oe-core and meta-clang llvm coexsting?

On 03/31/2017 03:53 PM, Martin Kelly wrote: On 03/30/2017 04:58 PM, Martin Kelly wrote: On 03/30/2017 12:31 PM, Khem Raj wrote: On 3/30/17 12:20 PM, Martin Kelly wrote: Hi, I'm trying to integrate the meta-clang version of LLVM 4.0 (used for recipes that need a newer LLVM version

Re: [OE-core] [meta-clang] LLVM shared library support

On 03/09/2017 01:06 PM, Khem Raj wrote: On Fri, Mar 3, 2017 at 12:09 PM, Khem Raj wrote: meta-clang has only provided static compiler thus far, so using shared or static did not matter as much in fact it could be helping with faster compile times that we see with clang.

Re: [OE-core] [meta-clang] LLVM shared library support

On 03/09/2017 09:20 PM, Khem Raj wrote: slow down is 6x when using clang to compile on target, I dont know if such a patch would be a good thing from compiler pov. I definitely understand the drawbacks of a slowdown. That said, some programs (such as the one I'm working on packaging) don't

[OE-core] [meta-clang] clang/LLVM versioning

Hi, I'm attempting to build a recipe using the LLVM/clang cross toolchain provided in meta-clang. However, I'm hitting issues with the llvm-config wrapper in llvm-common. Specifically, it looks like the wrapper was copied over from the LLVM recipe in meta-oe, but the versioning logic was not

Re: [OE-core] [meta-clang] clang/LLVM versioning

On 03/03/2017 12:23 PM, Khem Raj wrote: On Fri, Mar 3, 2017 at 12:15 PM, Martin Kelly <mke...@xevo.com> wrote: On 03/03/2017 12:12 PM, Khem Raj wrote: with meta-clang there is no desire to support multiple versions of llvm and thats why versioning was dropped however, I would stil

Re: [OE-core] [meta-clang] clang/LLVM versioning

On 03/03/2017 12:12 PM, Khem Raj wrote: with meta-clang there is no desire to support multiple versions of llvm and thats why versioning was dropped however, I would still like to fix the versioning if that makes it more useful. OK, keeping a single version is certainly simpler. Could you

[OE-core] [meta-clang] LLVM shared library support

Hi, I noticed that meta-clang builds only static LLVM libraries, unlike the meta-oe version of LLVM 3.3, which builds shared libraries. In fact, this appears to be the LLVM upstream default as well. What is the reason for the difference? Shared versions of LLVM would be useful for reducing

Re: [OE-core] Default rpaths in BUILD_LDFLAGS

On 03/08/2017 02:23 PM, Khem Raj wrote: On 17-03-08 13:56:12, Martin Kelly wrote: On 03/08/2017 01:46 PM, Khem Raj wrote: I agree we should not need them. Of course I can run a sed line to remove the rpaths from LLVM_LDFLAGS from tools/llvm-config/BuildVariables.inc (and this works just fine

Re: [OE-core] Default rpaths in BUILD_LDFLAGS

On 03/08/2017 04:02 PM, Khem Raj wrote: On 17-03-08 15:44:52, Martin Kelly wrote: On 03/08/2017 02:23 PM, Khem Raj wrote: On 17-03-08 13:56:12, Martin Kelly wrote: On 03/08/2017 01:46 PM, Khem Raj wrote: I agree we should not need them. Of course I can run a sed line to remove the rpaths

Re: [OE-core] Default rpaths in BUILD_LDFLAGS

On 03/08/2017 01:46 PM, Khem Raj wrote: On 17-03-07 16:43:47, Martin Kelly wrote: Hi, While debugging an issue with a package that uses llvm-config to compile with clang, I started hitting [rpaths] QA warnings because some output executables contained absolute rpaths pointing into my build

[OE-core] Default rpaths in BUILD_LDFLAGS

Hi, While debugging an issue with a package that uses llvm-config to compile with clang, I started hitting [rpaths] QA warnings because some output executables contained absolute rpaths pointing into my build directory. After tracing through the issue, I determined the rpaths to eventually

Re: [OE-core] [PATCH] qemuboot.conf: make cpus match built artifacts

On 04/24/2017 09:50 AM, Aníbal Limón wrote: Hi Martin, It looks that we need to improve the alignment between compiler flags and runqemu configurations. I don't know if is the right way to change the cpu's to pentium and core2due may be could cause side-effects. I think will be better to

Re: [OE-core] [poky] [PATCH] qemuboot.conf: make cpus match built artifacts

On 04/24/2017 09:31 AM, Richard Purdie wrote: On Fri, 2017-04-21 at 17:21 -0700, Martin Kelly wrote: Currently, the qemu CPUs for are specified as generic, but the built artifacts are not. For example, we build x86-64 artifacts targeting core2duo but run them in qemu with generic qemu/kvm CPUs

Re: [OE-core] [PATCH] licenses.conf: enable CDDLv1 license

(ping) On 07/10/2017 03:18 PM, Martin Kelly wrote: The CDDL license is now used by open-vm-tools in meta-openembedded, so we need to add it in order to prevent warnings. Signed-off-by: Martin Kelly <mke...@xevo.com> --- meta/conf/licenses.conf | 4 1 file changed, 4 insertions(+)

Re: [OE-core] [morty][PATCH 1/1] openssl-native: Compile with -fPIC

Hi, Is there any issue with backporting this to morty? It would help me fix a build crash I'm seeing on morty, and I'm currently using the backport in a separate repo with no issue. On 06/28/2017 11:06 AM, Martin Kelly wrote: On 05/26/2017 12:03 AM, Mirza Krak wrote: From: Khem Raj <ra

Re: [OE-core] [morty][PATCH 1/1] openssl-native: Compile with -fPIC

Hi Armin, Could we backport this patch to morty? On 07/11/2017 12:39 PM, Khem Raj wrote: On Tue, Jul 11, 2017 at 12:07 PM, Martin Kelly <mke...@xevo.com> wrote: Hi, Is there any issue with backporting this to morty? It would help me fix a build crash I'm seeing on morty, and I'm cur

[OE-core] [PATCH] licenses.conf: enable CDDLv1 license

The CDDL license is now used by open-vm-tools in meta-openembedded, so we need to add it in order to prevent warnings. Signed-off-by: Martin Kelly <mke...@xevo.com> --- meta/conf/licenses.conf | 4 1 file changed, 4 insertions(+) diff --git a/meta/conf/licenses.conf b/met

[OE-core] [PATCH] gstreamer1.0-python: add new recipe

, at this point, we have a gobject-introspection class, so we can use the bindings again, this time with GStreamer 1.0. Signed-off-by: Martin Kelly <mke...@xevo.com> --- .../gstreamer/gstreamer1.0-python.inc | 35 ++ .../gstreamer/gstreamer1.0-python_1.1

Re: [OE-core] [PATCH] gstreamer1.0-python: add new recipe

On 07/17/2017 07:47 PM, Khem Raj wrote: On Mon, Jul 17, 2017 at 8:21 PM, Martin Kelly <mke...@xevo.com> wrote: Previously, we had a gst-python recipe, but it supported only GStreamer 0.1. After GStreamer switched the Python bindings to use GObject introspection, we were no longer able to

Re: [OE-core] [PATCH] gstreamer1.0-python: add new recipe

On 07/18/2017 11:37 AM, Khem Raj wrote: On Tue, Jul 18, 2017 at 12:21 PM, Martin Kelly <mke...@xevo.com> wrote: On 07/17/2017 07:47 PM, Khem Raj wrote: On Mon, Jul 17, 2017 at 8:21 PM, Martin Kelly <mke...@xevo.com> wrote: Previously, we had a gst-python recipe, but it su

[OE-core] [PATCH v2] gstreamer1.0-python: add new recipe

, at this point, we have a gobject-introspection class, so we can use the bindings again, this time with GStreamer 1.0. Signed-off-by: Martin Kelly <mke...@xevo.com> --- .../gstreamer/gstreamer1.0-python.inc | 35 ++ .../gstreamer/gstreamer1.0-python_1.1

Re: [OE-core] [morty][PATCH 1/1] openssl-native: Compile with -fPIC

On 05/26/2017 12:03 AM, Mirza Krak wrote: From: Khem Raj Fixes | /usr/bin/ld: libcrypto.a(sha1-x86_64.o): relocation R_X86_64_PC32 against undefined symbol `OPENSSL_ia32cap_P' can not be used when making a shared object; recompile with -fPIC | /usr/bin/ld: final link

Re: [OE-core] [PATCH 1/1] tcf-agent: add -USR2 to stop/kill initscript

Looks like this is addressing the same problem as Jan's patch from earlier today. I think the differences are: - kill vs start-stop-daemon - Jan removed the retry loop while this patch does not On 05/01/2017 02:59 PM, brian avery wrote: The current initscript was lacking a -USR2 signal in

Re: [OE-core] [PATCH resend] qemuboot.conf: make cpus match built artifacts

On 05/22/2017 10:53 AM, Randy Witt wrote: On 05/22/2017 10:29 AM, Martin Kelly wrote: (friendly ping) On 05/02/2017 12:20 PM, Martin Kelly wrote: Currently, the qemu CPUs for are specified as generic, but the built artifacts are not. For example, we build x86-64 artifacts targeting core2duo

Re: [OE-core] [PATCH resend] qemuboot.conf: make cpus match built artifacts

(friendly ping) On 05/02/2017 12:20 PM, Martin Kelly wrote: Currently, the qemu CPUs for are specified as generic, but the built artifacts are not. For example, we build x86-64 artifacts targeting core2duo but run them in qemu with generic qemu/kvm CPUs. This causes some packages that take

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

On 05/02/2017 01:41 AM, Martin Kelly wrote: On 04/30/2017 08:28 AM, Jan Kiszka wrote: From: Jan Kiszka <jan.kis...@siemens.com> The upstream init script uses SIGUSR2 to terminate that daemon because SIGTERM is ignored. As the killproc function does not support specifying a signal,

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

On 06/07/2017 09:08 AM, Burton, Ross wrote: On 6 June 2017 at 18:28, Martin Kelly <mke...@xevo.com <mailto:mke...@xevo.com>> wrote: I sent a separate patch for fixing the systemd issue, so I think we can merge the two patches separately (they're both needed)

[OE-core] [PATCH] tcf-agent: kill with USR2 in systemd stop

, not the systemd service file. This patch fixes the systemd file. Signed-off-by: Martin Kelly <mke...@xevo.com> --- meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.service | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.service b/meta/r

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

On 06/01/2017 09:17 AM, Martin Kelly wrote: On 05/02/2017 01:41 AM, Martin Kelly wrote: On 04/30/2017 08:28 AM, Jan Kiszka wrote: From: Jan Kiszka <jan.kis...@siemens.com> The upstream init script uses SIGUSR2 to terminate that daemon because SIGTERM is ignored. As the killproc functio

Re: [OE-core] [PATCH resend] qemuboot.conf: make cpus match built artifacts

On 06/15/2017 04:45 AM, Burton, Ross wrote: On 2 May 2017 at 20:20, Martin Kelly <mke...@xevo.com <mailto:mke...@xevo.com>> wrote: -QB_CPU_KVM_x86-64 = "-cpu kvm64" +QB_CPU_KVM_x86-64 = "-cpu core2duo" What's the actual meaning of the "kvm64"

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

On 06/13/2017 09:52 AM, Burton, Ross wrote: On 13 June 2017 at 17:46, Martin Kelly <mke...@xevo.com <mailto:mke...@xevo.com>> wrote: Ah, I was checking meta-openembedded by mistake. Thanks. The Best Known Method is to have a oe-core clone that you use for pushing st

Re: [OE-core] [PATCH resend] qemuboot.conf: make cpus match built artifacts

On 05/22/2017 11:09 AM, Martin Kelly wrote: On 05/22/2017 10:53 AM, Randy Witt wrote: On 05/22/2017 10:29 AM, Martin Kelly wrote: (friendly ping) On 05/02/2017 12:20 PM, Martin Kelly wrote: Currently, the qemu CPUs for are specified as generic, but the built artifacts are not. For example

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

On 06/07/2017 12:09 PM, Burton, Ross wrote: On 7 June 2017 at 17:33, Martin Kelly <mke...@xevo.com <mailto:mke...@xevo.com>> wrote: Which patch are you referring to? I used git send-email for the systemd patch, and it applies just fine for me on OE-core master (usi

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

On 06/13/2017 09:38 AM, Burton, Ross wrote: On 13 June 2017 at 17:35, Martin Kelly <mke...@xevo.com <mailto:mke...@xevo.com>> wrote: Alright, makes sense. Do the patches look OK to you? Yes, they're both in master now. Ah, I was checking meta-openembedded by mis

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

On 04/30/2017 08:28 AM, Jan Kiszka wrote: From: Jan Kiszka The upstream init script uses SIGUSR2 to terminate that daemon because SIGTERM is ignored. As the killproc function does not support specifying a signal, switch to start-stop-daemon. Drop the retry loop because

[OE-core] [PATCH resend] qemuboot.conf: make cpus match built artifacts

this by making packages like Qt not take advantage of CPU features. However, we will probably keep facing similar issues over time, so it's better to resolve them in a more enduring way. Fix this by making the qemu -cpu arguments match the built artifacts. Signed-off-by: Martin Kelly <mke...@xevo.

[OE-core] [PATCH] scripts/runqemu.README: fix typo

Signed-off-by: Martin Kelly <mke...@xevo.com> --- scripts/runqemu.README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/runqemu.README b/scripts/runqemu.README index 5908d83..da9abd7 100644 --- a/scripts/runqemu.README +++ b/scripts/runqemu.README @@ -35,7

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

On 06/06/2017 03:11 AM, Jan Kiszka wrote: On 2017-06-01 02:17, Martin Kelly wrote: On 05/02/2017 01:41 AM, Martin Kelly wrote: On 04/30/2017 08:28 AM, Jan Kiszka wrote: From: Jan Kiszka <jan.kis...@siemens.com> The upstream init script uses SIGUSR2 to terminate that daemon because S

[OE-core] [PATCH 2/2] systemctl-native: explicitly check target validity

so that the user can fix these issues. Signed-off-by: Martin Kelly <mke...@xevo.com> --- .../systemd/systemd-systemctl/systemctl| 37 ++ 1 file changed, 30 insertions(+), 7 deletions(-) diff --git a/meta/recipes-core/systemd/systemd-systemctl/systemctl

[OE-core] [PATCH 1/2] systemctl-native: add target.wants to target regex

The regex for acceptable systemd WantedBy/RequiredBy targets does not include target.wants, so a line like this: WantedBy=multi-user.target.wants gets silently ignored, even though it works fine on a real system. Signed-off-by: Martin Kelly <mke...@xevo.com> --- meta/recipes-core/s

[OE-core] [PATCH] python*native.bbclass: suppress user site dirs

Currently, $HOME/.local is being added into sys.path for the native Python, causing subtle host contamination. Suppress this by exporting PYTHONNOUSERSITE = "1" as documented in PEP 370. Signed-off-by: Martin Kelly <mke...@xevo.com> --- meta/classes/python3native.bbclass | 3 +

Re: [OE-core] ✗ patchtest: failure for meson bugfix

This is expected, as the patch is intended to apply to Alexander Kanavin's poky-contrib akanavin/meson branch, not oe-core master. On 11/15/2017 10:02 AM, Patchwork wrote: == Series Details == Series: meson bugfix Revision: 1 URL : https://patchwork.openembedded.org/series/9809/ State :

Re: [OE-core] [PATCH 1/7] meson: add a recipe and class from meta-oe

Hi, It looks to me like there are some changes here on top of a forked meson.bbclass from meta-oe. Did you rebase the changes on top of current meta-oe's meson? From a look at the git logs and file contents, it looks like it needs a rebase or we may drop some patches. On 11/15/2017 03:08

Re: [OE-core] [morty backport][PATCH 0/2] tcf-agent fixes

the fixes to Morty. Regards, Javier Viguera -- Jan Kiszka (1): tcf-agent: Fix daemon termination Martin Kelly (1): tcf-agent: kill with USR2 in systemd stop meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.init| 12 +--- meta/recipes-devtools/tcf-agent/tcf-agent/tcf

[OE-core] [PATCH 1/1] meson: export native env only for native build

the other native vars *only* for the native build. For target builds, these vars will get overridden by the cross file as we expect. Signed-off-by: Martin Kelly <mke...@xevo.com> --- meta/classes/meson.bbclass | 23 --- 1 file changed, 16 insertions(+), 7 deletions(-) diff

[OE-core] [PATCH 0/1] [poky-contrib] meson bugfix

This patch is intended to be applied on top of Alexander Kanavin's poky-contrib branch akanavin/meson in preparation for meson moving into OE-core. Martin Kelly (1): meson: export native env only for native build meta/classes/meson.bbclass | 23 --- 1 file changed, 16

Re: [OE-core] [PATCH 1/1] meson: export native env only for native build

On 11/16/2017 09:52 AM, Alexander Kanavin wrote: On 11/15/2017 07:53 PM, Martin Kelly wrote: +meson_do_configure_prepend_class-native() { +    export PKG_CONFIG="pkg-config-native" +} + What does this bit do? Should it go to a separate patch? Alex This is from Ross Burton's pat

Re: [OE-core] [PATCH 1/2] systemctl-native: add target.wants to target regex

wasn't enabled when it should be. Again, systemctl *should* fail and cause a build failure if that happens, but there could be some bug. On 11/09/2017 05:01 PM, Martin Kelly wrote: Got it, thanks. My patch *should* just convert runtime failures into compile-time failures, but it looks like we're

Re: [OE-core] [PATCH 1/7] meson: add a recipe and class from meta-oe

Correction: I took another look after merging in my meson patch, and I think your branch is fully current. On 11/15/2017 09:27 AM, Martin Kelly wrote: Hi, It looks to me like there are some changes here on top of a forked meson.bbclass from meta-oe. Did you rebase the changes on top

Re: [OE-core] [PATCH 1/2] systemctl-native: add target.wants to target regex

was implicated in a number of systemd-related boot failures on the autobuilder (https://autobuilder.yocto.io/builders/nightly-qa-extras/builds/553). I've not yet got around to looking at exactly what sanity test 5 and 7 do to trigger this. Ross On 8 November 2017 at 17:40, Martin Kelly <

Re: [OE-core] [PATCH 1/2] systemctl-native: add target.wants to target regex

(ping) for this patch series. On 10/16/2017 09:31 AM, Martin Kelly wrote: The regex for acceptable systemd WantedBy/RequiredBy targets does not include target.wants, so a line like this: WantedBy=multi-user.target.wants gets silently ignored, even though it works fine on a real system

Re: [OE-core] [meta-oe][PATCH 2/3] modemmanager: upgrade to 1.7.991

On 05/08/2018 12:29 PM, Martin Jansa wrote: Hi Martin, all meta-oe patches need to go to openembedded-devel ML. Thanks Of course, my bad. Resent now to oe-devel. On Tue, May 8, 2018 at 8:49 PM, Martin Kelly <mke...@xevo.com <mailto:mke...@xevo.com>> wrote: This version

[OE-core] [meta-oe][PATCH 2/3] modemmanager: upgrade to 1.7.991

This version has a ublox plugin for expanded modem support. The underlying issue that enum-conversion.patch fixes appears to already have been fixed upstream, so we can drop the patch. Signed-off-by: Martin Kelly <mke...@xevo.com> --- .../modemmanager/modemmanager/enum-conversion.patc

[OE-core] [meta-oe][PATCH 1/3] libmbim: upgrade to 1.16

This is needed for the next version of modemmanager. Signed-off-by: Martin Kelly <mke...@xevo.com> --- A similar patch was also sent by Khem Raj; that patch is just as good, but I wanted to send this in the same series because the modemmanager upgrade requires a libmbim upgrade. .../l

[OE-core] [meta-oe][PATCH 3/3] modemmanager: fix mbim disable string

The current string used to disable mbim is "--enable-mbim=no", which is producing a warning. It should be "--with-mdim=no", so change it. Signed-off-by: Martin Kelly <mke...@xevo.com> --- meta-oe/recipes-connectivity/modemmanager/modemmanager_1.7.991.bb | 2 +- 1 file

Re: [OE-core] [PATCH resend] qemuboot.conf: make cpus match built artifacts

On 04/25/2018 04:11 PM, Martin Jansa wrote: There are actually 3 we need to consider for lowest common denominator. The one we build for, the one we build on and the one where we will run the qemu in the end. I mean the core2duo is probably best match for core2-64 DEFAULT used by qemux86-64

[OE-core] [PATCH 7/7] meson: enable nativesdk

Currently, we can't build meson into SDKs because we don't autogenerate the required meson.cross file. Enable this by using the post-relocate hooks and generating a meson.cross file based on the SDK environment passed into the post-relocate hook. Signed-off-by: Martin Kelly --- meta/recipes

[OE-core] [PATCH 3/7] toolchain-shar-extract: allow non-sh post-relocate

Currently, we look only for scripts matching *.sh, which means we can't write post-relocate scripts in other languages. Expand this to allow any type of script. Signed-off-by: Martin Kelly --- meta/classes/toolchain-scripts.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[OE-core] [PATCH 4/7] toolchain-shar-extract: print post-relocate error

Currently, if a post-relocate script fails, it fails silently. We should be louder about this, as it likely indicates a broken SDK. Print a message if a post-relocate script fails. Signed-off-by: Martin Kelly --- meta/classes/toolchain-scripts.bbclass | 5 + 1 file changed, 5 insertions

[OE-core] [PATCH 2/7] nativesdk-python*: suppress user site dirs

ore commit 8fe9fb4d5a61dcbcb3fc5b9ee0234cc135af873f ("python*native.bbclass: suppress user site dirs"). Signed-off-by: Martin Kelly --- meta/recipes-devtools/python/python-scons-native_3.0.1.bb | 2 +- meta/recipes-devtools/python/python3_3.5.5.bb | 2 +- meta/recipes-devtools/python/python_2.7.1

[OE-core] [PATCH 6/7] meson: handle exe wrappers

-by: Martin Kelly --- ...ke-ExternalProgram-get_path-a-bit-smarter.patch | 58 ++ ...mandrunner-make-run-handle-python-options.patch | 53 + .../0006-mesonlib-handle-meson-exe-wrappers.patch | 231 + meta/recipes-devtools/meson/meson_0.46.1.bb| 3 + 4 files changed

[OE-core] [PATCH 1/7] meson.bbclass: refactor native override

The native override is specified in two different places, so let's move it into a function to reduce code duplication. Signed-off-by: Martin Kelly --- meta/classes/meson.bbclass | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/meta/classes/meson.bbclass b

[OE-core] [PATCH 5/7] toolchain-shar-extract: pass env to post-relocate

It's useful for the post-relocate scripts to be able to see the SDK environment, for example to see the values of CC, CXX etc. in order to dynamically generate toolchain files. To enable this, source the SDK environment script prior to calling the relocate scripts. Signed-off-by: Martin Kelly

[OE-core] [PATCH 0/7] meson: implement nativesdk support

.html http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146262.html Martin Kelly (7): meson.bbclass: refactor native override nativesdk-python*: suppress user site dirs toolchain-shar-extract: allow non-sh post-relocate toolchain-shar-extract: print post-relocate error

Re: [OE-core] [PATCH v2 5/7] toolchain-shar-extract: pass env to post-relocate

On 06/04/2018 11:20 AM, Joshua Watt wrote: On Mon, 2018-06-04 at 11:10 -0700, Martin Kelly wrote: On 06/04/2018 10:20 AM, Joshua Watt wrote: On Fri, 2018-06-01 at 15:24 -0700, Martin Kelly wrote: On 06/01/2018 03:08 PM, Joshua Watt wrote: On Fri, 2018-06-01 at 14:02 -0700, Martin Kelly wrote

Re: [OE-core] [PATCH v2 5/7] toolchain-shar-extract: pass env to post-relocate

On 06/04/2018 10:20 AM, Joshua Watt wrote: On Fri, 2018-06-01 at 15:24 -0700, Martin Kelly wrote: On 06/01/2018 03:08 PM, Joshua Watt wrote: On Fri, 2018-06-01 at 14:02 -0700, Martin Kelly wrote: It's useful for the post-relocate scripts to be able to see the SDK environment, for example

Re: [OE-core] [PATCH v2 5/7] toolchain-shar-extract: pass env to post-relocate

On 06/04/2018 11:42 AM, Joshua Watt wrote: On Mon, 2018-06-04 at 11:24 -0700, Martin Kelly wrote: On 06/04/2018 11:20 AM, Joshua Watt wrote: On Mon, 2018-06-04 at 11:10 -0700, Martin Kelly wrote: On 06/04/2018 10:20 AM, Joshua Watt wrote: On Fri, 2018-06-01 at 15:24 -0700, Martin Kelly wrote

[OE-core] [PATCH v3 4/6] toolchain-scripts: pass env to post-relocate

It's useful for the post-relocate scripts to be able to see the SDK environment, for example to see the values of CC, CXX etc. in order to dynamically generate toolchain files. To enable this, source the SDK environment script prior to calling the relocate scripts. Signed-off-by: Martin Kelly

[OE-core] [PATCH v3 5/6] meson: handle exe wrappers

-by: Martin Kelly --- v2: - Switch to new version of patches to fix exe wrappers, as upstream tweaked the previous patch. ...0004-Prettifying-some-output-with-pathlib.patch | 188 + ...on-command-to-use-when-we-know-what-it-is.patch | 851 + meta/recipes-devtools/meson

[OE-core] [PATCH v3 3/6] toolchain-scripts: print post-relocate error

Currently, if a post-relocate script fails, it fails silently. We should be louder about this, as it likely indicates a broken SDK. Print a message if a post-relocate script fails. Signed-off-by: Martin Kelly --- meta/classes/toolchain-scripts.bbclass | 5 + 1 file changed, 5 insertions

[OE-core] [PATCH v3 6/6] meson: enable nativesdk

Currently, we can't build meson into SDKs because we don't autogenerate the required meson.cross file. Enable this by using the post-relocate hooks and generating a meson.cross file based on the SDK environment passed into the post-relocate hook. Signed-off-by: Martin Kelly --- meta/recipes

[OE-core] [PATCH v3 0/6] meson: implement nativesdk support

.html http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146262.html v3: - Implement review feedback from Joshua Watt (thanks!). v2: - Switch to new version of patches to fix exe wrappers, as upstream tweaked the previous patch. Martin Kelly (6): toolchain-scripts: retab file

[OE-core] [PATCH v3 2/6] toolchain-scripts: allow non-sh post-relocate

Currently, we look only for scripts matching *.sh, which means we can't write post-relocate scripts in other languages. Expand this to allow any type of script. Signed-off-by: Martin Kelly --- v3: - Test for executability prior to running each script. meta/classes/toolchain-scripts.bbclass

[OE-core] [PATCH v3 1/6] toolchain-scripts: retab file

Two functions is uses a mix of spaces and tabs. The rest of the file uses tabs, so switch to tabs uniformly. Signed-off-by: Martin Kelly --- meta/classes/toolchain-scripts.bbclass | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/meta/classes/toolchain

[OE-core] [PATCH v2 0/7] meson: implement nativesdk support

.html http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146262.html v2: - Switch to new version of patches to fix exe wrappers, as upstream tweaked the previous patch. Martin Kelly (7): meson.bbclass: refactor native override nativesdk-python*: suppress user site dirs

Re: [OE-core] [PATCH v2 5/7] toolchain-shar-extract: pass env to post-relocate

On 06/01/2018 03:08 PM, Joshua Watt wrote: On Fri, 2018-06-01 at 14:02 -0700, Martin Kelly wrote: It's useful for the post-relocate scripts to be able to see the SDK environment, for example to see the values of CC, CXX etc. in order to dynamically generate toolchain files. To enable

Re: [OE-core] [PATCH v2 4/7] toolchain-shar-extract: print post-relocate error

On 06/01/2018 02:57 PM, Joshua Watt wrote: On Fri, 2018-06-01 at 14:02 -0700, Martin Kelly wrote: Currently, if a post-relocate script fails, it fails silently. We should be louder about this, as it likely indicates a broken SDK. Print a message if a post-relocate script fails. Signed-off

[OE-core] [PATCH v2 6/7] meson: handle exe wrappers

-by: Martin Kelly --- v2: - Switch to new version of patches to fix exe wrappers, as upstream tweaked the previous patch. ...0004-Prettifying-some-output-with-pathlib.patch | 188 + ...on-command-to-use-when-we-know-what-it-is.patch | 851 + meta/recipes-devtools/meson

[OE-core] [PATCH v2 7/7] meson: enable nativesdk

Currently, we can't build meson into SDKs because we don't autogenerate the required meson.cross file. Enable this by using the post-relocate hooks and generating a meson.cross file based on the SDK environment passed into the post-relocate hook. Signed-off-by: Martin Kelly --- meta/recipes

[OE-core] [PATCH v2 2/7] nativesdk-python*: suppress user site dirs

ore commit 8fe9fb4d5a61dcbcb3fc5b9ee0234cc135af873f ("python*native.bbclass: suppress user site dirs"). Signed-off-by: Martin Kelly --- meta/recipes-devtools/python/python-scons-native_3.0.1.bb | 2 +- meta/recipes-devtools/python/python3_3.5.5.bb | 2 +- meta/recipes-devtools/python/python_2.7.1

[OE-core] [PATCH v2 3/7] toolchain-shar-extract: allow non-sh post-relocate

Currently, we look only for scripts matching *.sh, which means we can't write post-relocate scripts in other languages. Expand this to allow any type of script. Signed-off-by: Martin Kelly --- meta/classes/toolchain-scripts.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[OE-core] [PATCH v2 4/7] toolchain-shar-extract: print post-relocate error

Currently, if a post-relocate script fails, it fails silently. We should be louder about this, as it likely indicates a broken SDK. Print a message if a post-relocate script fails. Signed-off-by: Martin Kelly --- meta/classes/toolchain-scripts.bbclass | 5 + 1 file changed, 5 insertions

[OE-core] [PATCH v2 1/7] meson.bbclass: refactor native override

The native override is specified in two different places, so let's move it into a function to reduce code duplication. Signed-off-by: Martin Kelly --- meta/classes/meson.bbclass | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/meta/classes/meson.bbclass b

[OE-core] [PATCH v2 5/7] toolchain-shar-extract: pass env to post-relocate

It's useful for the post-relocate scripts to be able to see the SDK environment, for example to see the values of CC, CXX etc. in order to dynamically generate toolchain files. To enable this, source the SDK environment script prior to calling the relocate scripts. Signed-off-by: Martin Kelly

Re: [OE-core] [PATCH v3 1/6] toolchain-scripts: retab file

On 06/05/2018 05:04 AM, Peter Kjellerstedt wrote: -Original Message- From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] Sent: den 5 juni 2018 12:37 To: Peter Kjellerstedt ; Martin Kelly ; openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH v3 1/6

Re: [OE-core] [PATCH] icecc-toolchain: Remove environment setup

_PATH" ]; then exit 0 Reviewed-by: Martin Kelly -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Issues with meson in SDK with cross-file

On 01/09/2018 10:40 AM, Jussi Pakkanen wrote: On Tue, Jan 9, 2018 at 8:20 PM, Martin Kelly <mke...@xevo.com> wrote: Note the "native C compiler" line, which directly uses $CC. I'm not sure if this is correct, but an easy way to fix the issue is to ignore $CC for internal sani

[OE-core] Issues with meson in SDK with cross-file

[Jussi Pakkanen, Nirbheek Chauhan, I know you may not be on the list; I added you to get Yocto/OE and meson upstream all on the same thread to discuss integrating the two] Hi all, Recently, we got meson added to OE-core as part of Yocto (thanks Alexander Kanavin!). That said, it doesn't yet

Re: [OE-core] Issues with meson in SDK with cross-file

+CC Khem Raj, who has done a lot of work on the SDK and may have an opinion about handling relocatable cross files. On 01/09/2018 01:50 AM, Nirbheek Chauhan wrote: On Tue, Jan 9, 2018 at 5:21 AM, Martin Kelly <mke...@xevo.com> wrote: [Jussi Pakkanen, Nirbheek Chauhan, I know y

Re: [OE-core] Issues with meson in SDK with cross-file

On 01/09/2018 02:06 AM, Nirbheek Chauhan wrote: On Tue, Jan 9, 2018 at 3:20 PM, Nirbheek Chauhan wrote: If we want to setup a cross-file to use these arguments, we would have to generate the cross-file on-the-fly (not good). Out of interest, why is that not good?

Re: [OE-core] [PATCH 2/9] gnomebase-meson.bbclass: add a meson-specific version

On 01/05/2018 06:57 AM, Alexander Kanavin wrote: On 01/05/2018 01:47 PM, Burton, Ross wrote: Do we even need gnomebase-meson with this?  I can see a future where GNOME is entirely Meson and then we could just switch the default GNOMEBASEBUILDCLASS from autotools to meson. (prior art being

Re: [OE-core] [PATCH 2/9] gnomebase-meson.bbclass: add a meson-specific version

On 01/10/2018 10:48 AM, Richard Purdie wrote: On Wed, 2018-01-10 at 09:55 -0800, Martin Kelly wrote: On 01/05/2018 06:57 AM, Alexander Kanavin wrote: On 01/05/2018 01:47 PM, Burton, Ross wrote: Do we even need gnomebase-meson with this?  I can see a future where GNOME is entirely Meson

  1   2   >