buildroot/package/meson, branch 2019.02-op-build

package/meson: fix RPATH patch

2019-02-06T13:18:01+00:00

The re-added ([1]) patch missed to remove two lines of the original unconditional code. [1] https://git.buildroot.net/buildroot/commit/?id=5c939246a802c0ad9704dac1505105037542a1d3 Signed-off-by: Peter Seiderer Signed-off-by: Thomas Petazzoni

package/pkg-meson: support per-package directories

2019-01-17T21:52:41+00:00

Currently, package/meson/meson.mk generates a single global cross-compilation.conf file, with the path to the compiler, cflags, ldflags, and various other details. This file is then used when building all meson-based packages. This causes two problems: - It is not compatible with per-package directories, because with per-package folders, we need to use a different compiler, and possibly CFLAGS/LDFLAGS for each package. - It is not possible to define per package CFLAGS. Indeed, when cross-compiling, meson doesn't support passing CFLAGS through the environment, only the CFLAGS from cross-compilation.conf are taken into account. For this reason, this commit: - Introduces a per-package cross-compilation.conf, which is generated by the pkg-meson infrastructure in the "configure" step right before calling meson. The file is generated in $(@D)/build/, and because it is generated within a given package "configure" step, the compiler path is the one of this package. - Keeps the global cross-compilation.conf in $(HOST_DIR)/etc/meson/, for the SDK use-case of Buildroot. Since we want the final and global values of the compiler path, CFLAGS and LDFLAGS, generating this global cross-compilation.conf is moved to a TARGET_FINALIZE_HOOKS. If we were keeping this as a HOST_MESON_POST_INSTALL_HOOKS, it would contain values specific to the host-meson package. For now, we don't yet support per-package CFLAGS/LDFLAGS, but having such per-package cross-compilation.conf is a necessary preparation to achieve this goal. This commit has been tested by building all Buildroot packages that use meson: json-glib, systemd, enlightenment, at-spi2-core, ncmpc, libmpdclient and ncmpc. Signed-off-by: Peter Seiderer [Thomas: - add extended commit log - in pkg-meson.mk, re-use variables defined in meson.mk to do the replacement of CFLAGS/LDFLAGS/CXXFLAGS - move the generation of the global cross-compilation.conf to a TARGET_FINALIZE_HOOKS - testing with per-package folders] Signed-off-by: Thomas Petazzoni Tested-by: Peter Seiderer Signed-off-by: Peter Korsgaard

package/meson: bump to version 0.49.0

2019-01-01T10:24:14+00:00

This version requires host-python3-setuptools, because meson no longer falls back to distutils for its installation if setuptools cannot be found: setuptools *must* be available. Signed-off-by: James Hilliard Signed-off-by: Thomas Petazzoni

package/meson: fix CPU familly

2018-12-28T10:52:58+00:00

As explained in [0], meson recognises a certain set of CPU famillies, whose names slightly differ from those we know them as. If we don't pass the proper cpu_familly, meson whines: WARNING: Unknown CPU family 'i686', please report this at [...] Subsequently, packages that use that to decide on what they should build and how they should build it, fail to build. That is the case for the upcoming systemd-boot, for example. Fix that by using the list propvided by the meson documentation [0]. [0] https://mesonbuild.com/Reference-tables.html#cpu-families Signed-off-by: James Hilliard [yann.morin.1998@free.fr: - split in its own patch - imnprove commit log ] Signed-off-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni

package/meson: never try to run generated target binaries

2018-12-28T10:52:37+00:00

As explained in [0], meson will try on its own to decide whether it can run what it builds. If it happens that the host and target CPUs are "compatible", that test may fail and meson may believe it can run what it builds. Override that test by using needs_exe_wrapper=true, and not defining an actual exe_wrapper. [0] https://mesonbuild.com/Cross-compilation.html Signed-off-by: James Hilliard [yann.morin.1998@free.fr: - split in its own patch - improve commit log ] Signed-off-by: Yann E. MORIN Signed-off-by: Thomas Petazzoni

package/meson: bump to version 0.47.2

2018-11-09T21:24:37+00:00

Note, that there is already a patch [1] to bump the version to 0.48.1. However, the bump to version 0.48.x has some unresolved issues. In the meantime, until the issue with 0.48 is resolved, bump to latest version of the 0.47 branch. [1] http://patchwork.ozlabs.org/patch/986260/ Signed-off-by: Jörg Krause Signed-off-by: Thomas Petazzoni

meson: re-add patch for skipping RPATH fixing

2018-11-01T20:21:34+00:00

The patch to skip RPATH fixing performed by Meson was removed in commit a03f46ca6e9f43028003aedc92f1a1204ae7480f, as the script support/scripts/check-host-rpath was not complaining anymore. But without it, the problem still occurs for host packages [1]. So, restore this patch to fix build of host packages with Meson. [1] http://lists.busybox.net/pipermail/buildroot/2018-October/232956.html Signed-off-by: Eric Le Bihan Signed-off-by: Thomas Petazzoni

arch: allow GCC target options to be optionally overwritten

2018-09-23T20:17:57+00:00

The BR2_GCC_TARGET_* configuration variables are copied to corresponding GCC_TARGET_* variables which may then be optionally modified or overwritten by architecture specific makefiles. All makefiles must use the new GCC_TARGET_* variables instead of the BR2_GCC_TARGET_* versions. Signed-off-by: Mark Corbin [Thomas: simplify include of arch/arch.mk] Signed-off-by: Thomas Petazzoni

meson: bump version to 0.47.1

2018-08-16T11:51:46+00:00

- delete legacy patch 0001-Only-fix-RPATH-if-install_rpath-is-not-empty.patch (no complains from support/scripts/check-host-rpath even without the patch) Signed-off-by: Peter Seiderer Acked-by: Eric Le Bihan Tested-by: Eric Le Bihan Signed-off-by: Thomas Petazzoni

meson: bump version to 0.46.1

2018-06-09T14:41:54+00:00

Signed-off-by: Eric Le Bihan Signed-off-by: Peter Korsgaard