buildroot/package/pkg-meson.mk

274 lines
9.9 KiB
Makefile
Raw Normal View History

################################################################################
# Meson package infrastructure
#
# This file implements an infrastructure that eases development of
# package .mk files for Meson packages. It should be used for all
# packages that use Meson as their build system.
#
# See the Buildroot documentation for details on the usage of this
# infrastructure
#
# In terms of implementation, this Meson infrastructure requires
# the .mk file to only specify metadata information about the
# package: name, version, download URL, etc.
#
# We still allow the package .mk file to override what the different
# steps are doing, if needed. For example, if <PKG>_BUILD_CMDS is
# already defined, it is used as the list of commands to perform to
# build the package, instead of the default Meson behaviour. The
# package can also define some post operation hooks.
#
################################################################################
#
# Pass PYTHONNOUSERSITE environment variable when invoking Meson or Ninja, so
# $(HOST_DIR)/bin/python3 will not look for Meson modules in
# $HOME/.local/lib/python3.x/site-packages
#
MESON = PYTHONNOUSERSITE=y $(HOST_DIR)/bin/meson
NINJA = PYTHONNOUSERSITE=y $(HOST_DIR)/bin/ninja
NINJA_OPTS = $(if $(VERBOSE),-v)
# https://mesonbuild.com/Reference-tables.html#cpu-families
ifeq ($(BR2_arcle)$(BR2_arceb),y)
PKG_MESON_TARGET_CPU_FAMILY = arc
else ifeq ($(BR2_arm)$(BR2_armeb),y)
PKG_MESON_TARGET_CPU_FAMILY = arm
else ifeq ($(BR2_aarch64)$(BR2_aarch64_be),y)
PKG_MESON_TARGET_CPU_FAMILY = aarch64
else ifeq ($(BR2_i386),y)
PKG_MESON_TARGET_CPU_FAMILY = x86
else ifeq ($(BR2_m68k),y)
PKG_MESON_TARGET_CPU_FAMILY = m68k
else ifeq ($(BR2_microblazeel)$(BR2_microblazebe),y)
PKG_MESON_TARGET_CPU_FAMILY = microblaze
else ifeq ($(BR2_mips)$(BR2_mipsel),y)
PKG_MESON_TARGET_CPU_FAMILY = mips
else ifeq ($(BR2_mips64)$(BR2_mips64el),y)
PKG_MESON_TARGET_CPU_FAMILY = mips64
else ifeq ($(BR2_powerpc),y)
PKG_MESON_TARGET_CPU_FAMILY = ppc
else ifeq ($(BR2_powerpc64)$(BR2_powerpc64le),y)
PKG_MESON_TARGET_CPU_FAMILY = ppc64
else ifeq ($(BR2_riscv)$(BR2_RISCV_32),yy)
PKG_MESON_TARGET_CPU_FAMILY = riscv32
else ifeq ($(BR2_riscv)$(BR2_RISCV_64),yy)
PKG_MESON_TARGET_CPU_FAMILY = riscv64
else ifeq ($(BR2_s390x),y)
PKG_MESON_TARGET_CPU_FAMILY = s390x
else ifeq ($(BR2_sh4)$(BR2_sh4eb)$(BR2_sh4a)$(BR2_sh4aeb),y)
PKG_MESON_TARGET_CPU_FAMILY = sh4
else ifeq ($(BR2_sparc),y)
PKG_MESON_TARGET_CPU_FAMILY = sparc
else ifeq ($(BR2_sparc64),y)
PKG_MESON_TARGET_CPU_FAMILY = sparc64
else ifeq ($(BR2_x86_64),y)
PKG_MESON_TARGET_CPU_FAMILY = x86_64
else
PKG_MESON_TARGET_CPU_FAMILY = $(ARCH)
endif
# To avoid populating the cross-file with non existing compilers,
# we tie them to /bin/false
ifeq ($(BR2_INSTALL_LIBSTDCPP),y)
PKG_MESON_TARGET_CXX = $(TARGET_CXX)
else
PKG_MESON_TARGET_CXX = /bin/false
endif
ifeq ($(BR2_TOOLCHAIN_HAS_FORTRAN),y)
PKG_MESON_TARGET_FC = $(TARGET_FC)
else
PKG_MESON_TARGET_FC = /bin/false
endif
# Generates sed patterns for patching the cross-compilation.conf template,
# since Flags might contain commas the arguments are passed indirectly by
# variable name (stripped to deal with whitespaces).
# Arguments are variable containing cflags, cxxflags, ldflags, fcflags
define PKG_MESON_CROSSCONFIG_SED
-e "s%@TARGET_CC@%$(TARGET_CC)%g" \
-e "s%@TARGET_CXX@%$(PKG_MESON_TARGET_CXX)%g" \
-e "s%@TARGET_AR@%$(TARGET_AR)%g" \
-e "s%@TARGET_FC@%$(PKG_MESON_TARGET_FC)%g" \
-e "s%@TARGET_STRIP@%$(TARGET_STRIP)%g" \
-e "s%@TARGET_ARCH@%$(PKG_MESON_TARGET_CPU_FAMILY)%g" \
-e "s%@TARGET_CPU@%$(GCC_TARGET_CPU)%g" \
-e "s%@TARGET_ENDIAN@%$(call qstrip,$(call LOWERCASE,$(BR2_ENDIAN)))%g" \
-e "s%@TARGET_FCFLAGS@%$(call make-sq-comma-list,$($(strip $(4))))%g" \
-e "s%@TARGET_CFLAGS@%$(call make-sq-comma-list,$($(strip $(1))))%g" \
-e "s%@TARGET_LDFLAGS@%$(call make-sq-comma-list,$($(strip $(3))))%g" \
-e "s%@TARGET_CXXFLAGS@%$(call make-sq-comma-list,$($(strip $(2))))%g" \
-e "s%@BR2_CMAKE@%$(BR2_CMAKE)%g" \
-e "s%@PKGCONF_HOST_BINARY@%$(HOST_DIR)/bin/pkgconf%g" \
-e "s%@HOST_DIR@%$(HOST_DIR)%g" \
-e "s%@STAGING_DIR@%$(STAGING_DIR)%g" \
-e "s%@STATIC@%$(if $(BR2_STATIC_LIBS),true,false)%g" \
$(TOPDIR)/support/misc/cross-compilation.conf.in
endef
################################################################################
# inner-meson-package -- defines how the configuration, compilation and
# installation of a Meson package should be done, implements a few hooks to
# tune the build process and calls the generic package infrastructure to
# generate the necessary make targets
#
# argument 1 is the lowercase package name
# argument 2 is the uppercase package name, including a HOST_ prefix
# for host packages
# argument 3 is the uppercase package name, without the HOST_ prefix
# for host packages
# argument 4 is the type (target or host)
################################################################################
define inner-meson-package
#
# Configure step. Only define it if not already defined by the package
# .mk file. And take care of the differences between host and target
# packages.
#
ifndef $(2)_CONFIGURE_CMDS
ifeq ($(4),target)
infra/pkg-meson: allow packages to pass custom compiler/linker flags Meson does not allow to pass CFLAGS/LDFLAGS/CXXFLAGS via the environment or via command-line arguments or options (instead, those flags from the environment are passed to the host compiler, which is seldom what we need). The only way to pas those flags is via the cross-compilation.conf file. Add LIBFOO_CFLAGS, LIBFOO_LDFLAGS and LIBFOO_CXXFLAGS variables to allow packages to provide their own flags, possibly overriding the generic ones entirely, as we allow for other infras. Those per-package flags will then be used to generate the per-package cross-compilation.conf. This means that the meson infra is the first and only infra for which FOO_CFLAGS, FOO_LDFLAGS, and FOO_CXXFLAGS are meaningful, while for the other infras, they are just variables private to the package itself. Instead of naming those variables after the meson infra (e.g. FOO_MESON_CFLAGS), we name them with a generic name, as maybe, just maybe, we could also change the other infras to also recognise those variables. Just like for the HOST_MESON_SED_CFLAGS etc., we need to add auxiliary variables to do convert the shell-formatted argument list into the JSON-formatted list that meson expects. We can't use a pure-make construct because the CFLAGS can contain quoting that needs to be expanded by the shell. Similarly, we need a condition on the strip'ed variable to avoid passing empty arguments. To mimic this feature for packages that are built from the SDK, we also install a templatised version of cross-compilation.conf, with three new placeholders for custom flags. If a user wants to build a package that needs custom flags, they can use that template to generate a per-package cross-compilation.conf. Signed-off-by: Peter Seiderer <ps.report@gmx.net> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Adam Duskett <aduskett@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Tested-by: Peter Seiderer <ps.report@gmx.net> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-06-24 14:25:48 -06:00
$(2)_CFLAGS ?= $$(TARGET_CFLAGS)
$(2)_LDFLAGS ?= $$(TARGET_LDFLAGS)
$(2)_CXXFLAGS ?= $$(TARGET_CXXFLAGS)
# Configure package for target
#
#
define $(2)_CONFIGURE_CMDS
rm -rf $$($$(PKG)_SRCDIR)/build
mkdir -p $$($$(PKG)_SRCDIR)/build
sed -e "/^\[binaries\]$$$$/s:$$$$:$$(foreach x,$$($(2)_MESON_EXTRA_BINARIES),\n$$(x)):" \
-e "/^\[properties\]$$$$/s:$$$$:$$(foreach x,$$($(2)_MESON_EXTRA_PROPERTIES),\n$$(x)):" \
$$(call PKG_MESON_CROSSCONFIG_SED,$(2)_CFLAGS,$(2)_CXXFLAGS,$(2)_LDFLAGS,$(2)_FCFLAGS) \
package/pkg-meson: support per-package directories 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 <ps.report@gmx.net> [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 <thomas.petazzoni@bootlin.com> Tested-by: Peter Seiderer <ps.report@gmx.net> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-11-30 03:40:03 -07:00
> $$($$(PKG)_SRCDIR)/build/cross-compilation.conf
package/pkg-meson.mk avoid host ccache detection meson will by default try to detect the presence of ccache, and if found, will use it unconditionally. However, using a system-wide ccache, which would be using our own cache directory, may very well conflict with our own ccache. But there is no option to disable that meson behaviour. The only workaround that is even the official documented way to do so, is to actually pass environment variables that point to the compiler: https://mesonbuild.com/Feature-autodetection.html#ccache For the host variants, we pass $(HOST_CONFIGURE_OPTS) in the environment, and this contains correct settings for CC and CXX, so meson does not try and detect ccache; it uses exactly what we tell it to use. For the target variant, the settings for the cross-compiler are defined in the cross-compilation file, and so meson just abides by our will. But for the compiler-for-build, there is no way to specify the CC_FOR_BUILD or CXX_FOR_BUILD via a cross-compilation file: https://mesonbuild.com/Machine-files.html https://mesonbuild.com/Cross-compilation.html We could pass the full TARGET_CONFIGURE_OPTS in the environment, like we do for the host variant, but this contains a lot more variables that are supposed to be covered by the cross-compilation file. So, we stay safe and just provide the exact two variables that meson will use to avoid detecting ccache. If the current configuration defines the use of ccache, then these two variables will be properly setup to use our own ccache. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Gleb Mazovetskiy <glex.spb@gmail.com> Cc: James Hilliard <james.hilliard1@gmail.com> Cc: Norbert Lange <nolange79@gmail.com>
2021-01-10 04:19:21 -07:00
PATH=$$(BR_PATH) \
CC_FOR_BUILD="$$(HOSTCC)" \
CXX_FOR_BUILD="$$(HOSTCXX)" \
package/pkg-meson.mk avoid host ccache detection meson will by default try to detect the presence of ccache, and if found, will use it unconditionally. However, using a system-wide ccache, which would be using our own cache directory, may very well conflict with our own ccache. But there is no option to disable that meson behaviour. The only workaround that is even the official documented way to do so, is to actually pass environment variables that point to the compiler: https://mesonbuild.com/Feature-autodetection.html#ccache For the host variants, we pass $(HOST_CONFIGURE_OPTS) in the environment, and this contains correct settings for CC and CXX, so meson does not try and detect ccache; it uses exactly what we tell it to use. For the target variant, the settings for the cross-compiler are defined in the cross-compilation file, and so meson just abides by our will. But for the compiler-for-build, there is no way to specify the CC_FOR_BUILD or CXX_FOR_BUILD via a cross-compilation file: https://mesonbuild.com/Machine-files.html https://mesonbuild.com/Cross-compilation.html We could pass the full TARGET_CONFIGURE_OPTS in the environment, like we do for the host variant, but this contains a lot more variables that are supposed to be covered by the cross-compilation file. So, we stay safe and just provide the exact two variables that meson will use to avoid detecting ccache. If the current configuration defines the use of ccache, then these two variables will be properly setup to use our own ccache. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Gleb Mazovetskiy <glex.spb@gmail.com> Cc: James Hilliard <james.hilliard1@gmail.com> Cc: Norbert Lange <nolange79@gmail.com>
2021-01-10 04:19:21 -07:00
$$($$(PKG)_CONF_ENV) \
$$(MESON) setup \
--prefix=/usr \
--libdir=lib \
--default-library=$(if $(BR2_STATIC_LIBS),static,shared) \
--buildtype=$(if $(BR2_ENABLE_RUNTIME_DEBUG),debug,release) \
package/pkg-meson: support per-package directories 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 <ps.report@gmx.net> [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 <thomas.petazzoni@bootlin.com> Tested-by: Peter Seiderer <ps.report@gmx.net> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-11-30 03:40:03 -07:00
--cross-file=$$($$(PKG)_SRCDIR)/build/cross-compilation.conf \
-Db_pie=false \
-Db_staticpic=$(if $(BR2_m68k_cf),false,true) \
-Dstrip=false \
-Dbuild.pkg_config_path=$$(HOST_DIR)/lib/pkgconfig \
-Dbuild.cmake_prefix_path=$$(HOST_DIR)/lib/cmake \
$$($$(PKG)_CONF_OPTS) \
$$($$(PKG)_SRCDIR) $$($$(PKG)_SRCDIR)/build
endef
else
# Configure package for host
define $(2)_CONFIGURE_CMDS
rm -rf $$($$(PKG)_SRCDIR)/build
mkdir -p $$($$(PKG)_SRCDIR)/build
$$(HOST_CONFIGURE_OPTS) \
$$($$(PKG)_CONF_ENV) $$(MESON) setup \
--prefix=$$(HOST_DIR) \
--libdir=lib \
--sysconfdir=$$(HOST_DIR)/etc \
--localstatedir=$$(HOST_DIR)/var \
--default-library=shared \
--buildtype=release \
--wrap-mode=nodownload \
-Dstrip=true \
$$($$(PKG)_CONF_OPTS) \
$$($$(PKG)_SRCDIR) $$($$(PKG)_SRCDIR)/build
endef
endif
endif
$(2)_DEPENDENCIES += host-meson
#
# Build step. Only define it if not already defined by the package .mk
# file.
#
ifndef $(2)_BUILD_CMDS
ifeq ($(4),target)
define $(2)_BUILD_CMDS
$$(TARGET_MAKE_ENV) $$($$(PKG)_NINJA_ENV) \
$$(NINJA) $$(NINJA_OPTS) $$($$(PKG)_NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build
endef
else
define $(2)_BUILD_CMDS
$$(HOST_MAKE_ENV) $$($$(PKG)_NINJA_ENV) \
$$(NINJA) $$(NINJA_OPTS) $$($$(PKG)_NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build
endef
endif
endif
#
# Host installation step. Only define it if not already defined by the
# package .mk file.
#
ifndef $(2)_INSTALL_CMDS
define $(2)_INSTALL_CMDS
$$(HOST_MAKE_ENV) $$($$(PKG)_NINJA_ENV) \
$$(NINJA) $$(NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build install
endef
endif
#
# Staging installation step. Only define it if not already defined by
# the package .mk file.
#
ifndef $(2)_INSTALL_STAGING_CMDS
define $(2)_INSTALL_STAGING_CMDS
$$(TARGET_MAKE_ENV) $$($$(PKG)_NINJA_ENV) DESTDIR=$$(STAGING_DIR) \
$$(NINJA) $$(NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build install
endef
endif
#
# Target installation step. Only define it if not already defined by
# the package .mk file.
#
ifndef $(2)_INSTALL_TARGET_CMDS
define $(2)_INSTALL_TARGET_CMDS
$$(TARGET_MAKE_ENV) $$($$(PKG)_NINJA_ENV) DESTDIR=$$(TARGET_DIR) \
$$(NINJA) $$(NINJA_OPTS) -C $$($$(PKG)_SRCDIR)/build install
endef
endif
# Call the generic package infrastructure to generate the necessary
# make targets
$(call inner-generic-package,$(1),$(2),$(3),$(4))
endef
################################################################################
# meson-package -- the target generator macro for Meson packages
################################################################################
meson-package = $(call inner-meson-package,$(pkgname),$(call UPPERCASE,$(pkgname)),$(call UPPERCASE,$(pkgname)),target)
host-meson-package = $(call inner-meson-package,host-$(pkgname),$(call UPPERCASE,host-$(pkgname)),$(call UPPERCASE,$(pkgname)),host)
package/meson: install cross-compilation.conf during toolchain install package/meson installs a cross-compilation.conf file in $(HOST_DIR)/etc/meson, via TARGET_FINALIZE_HOOKS. package/pkg-cmake.mk installs a toolchainfile.cmake in $(HOST_DIR)/share/buildroot, via TOOLCHAIN_POST_INSTALL_STAGING_HOOKS. Both files have a similar concept, they describe some flags/paths needed for compilation using respective build systems. One difference is that the meson file is added for external compilation, from the SDK, while the cmake file is used internally in Buildroot. The 'problem' of using TARGET_FINALIZE_HOOKS for the meson file, is that it installs a 'host' file from target-finalize, which is conceptually incorrect since not just TARGET_DIR but also HOST_DIR is "regenerated" on a subsequent 'make' when everything was already built (i.e. only target-finalize is run). This can easily be fixed, by using the same hook as cmake uses, i.e. TOOLCHAIN_POST_INSTALL_STAGING_HOOKS. Note that actually even for cmake, TOOLCHAIN_POST_INSTALL_STAGING_HOOKS is not the best hook to install a host file. A better hook would have been TOOLCHAIN_POST_INSTALL_HOOKS, but this triggers only for 'host' packages, and 'toolchain' is treated as a 'target' package. Also, the hook (and therefore also the definition of PKG_MESON_INSTALL_CROSS_CONF) is moved to pkg-meson.mk, again to make it more similar to how it's done for cmake. Otherwise check-package complains that the meson package is setting variables that don't start with MESON_. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-02-25 14:11:46 -07:00
################################################################################
# Generation of the Meson compile flags and cross-compilation file
package/meson: install cross-compilation.conf during toolchain install package/meson installs a cross-compilation.conf file in $(HOST_DIR)/etc/meson, via TARGET_FINALIZE_HOOKS. package/pkg-cmake.mk installs a toolchainfile.cmake in $(HOST_DIR)/share/buildroot, via TOOLCHAIN_POST_INSTALL_STAGING_HOOKS. Both files have a similar concept, they describe some flags/paths needed for compilation using respective build systems. One difference is that the meson file is added for external compilation, from the SDK, while the cmake file is used internally in Buildroot. The 'problem' of using TARGET_FINALIZE_HOOKS for the meson file, is that it installs a 'host' file from target-finalize, which is conceptually incorrect since not just TARGET_DIR but also HOST_DIR is "regenerated" on a subsequent 'make' when everything was already built (i.e. only target-finalize is run). This can easily be fixed, by using the same hook as cmake uses, i.e. TOOLCHAIN_POST_INSTALL_STAGING_HOOKS. Note that actually even for cmake, TOOLCHAIN_POST_INSTALL_STAGING_HOOKS is not the best hook to install a host file. A better hook would have been TOOLCHAIN_POST_INSTALL_HOOKS, but this triggers only for 'host' packages, and 'toolchain' is treated as a 'target' package. Also, the hook (and therefore also the definition of PKG_MESON_INSTALL_CROSS_CONF) is moved to pkg-meson.mk, again to make it more similar to how it's done for cmake. Otherwise check-package complains that the meson package is setting variables that don't start with MESON_. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-02-25 14:11:46 -07:00
################################################################################
# Generate a Meson cross-compilation.conf suitable for use with the
# SDK; also install the file as a template for users to add their
# own flags if they need to.
define PKG_MESON_INSTALL_CROSS_CONF
mkdir -p $(HOST_DIR)/etc/meson
sed -e "s%@TARGET_CFLAGS@%$(call make-sq-comma-list,$(TARGET_CFLAGS))@PKG_TARGET_CFLAGS@%g" \
-e "s%@TARGET_LDFLAGS@%$(call make-sq-comma-list,$(TARGET_LDFLAGS))@PKG_TARGET_LDFLAGS@%g" \
-e "s%@TARGET_CXXFLAGS@%$(call make-sq-comma-list,$(TARGET_CXXFLAGS))@PKG_TARGET_CXXFLAGS@%g" \
-e "s%@TARGET_FCFLAGS@%$(call make-sq-comma-list,$(TARGET_FCFLAGS))@PKG_TARGET_FCFLAGS@%g" \
$(call PKG_MESON_CROSSCONFIG_SED) \
package/meson: install cross-compilation.conf during toolchain install package/meson installs a cross-compilation.conf file in $(HOST_DIR)/etc/meson, via TARGET_FINALIZE_HOOKS. package/pkg-cmake.mk installs a toolchainfile.cmake in $(HOST_DIR)/share/buildroot, via TOOLCHAIN_POST_INSTALL_STAGING_HOOKS. Both files have a similar concept, they describe some flags/paths needed for compilation using respective build systems. One difference is that the meson file is added for external compilation, from the SDK, while the cmake file is used internally in Buildroot. The 'problem' of using TARGET_FINALIZE_HOOKS for the meson file, is that it installs a 'host' file from target-finalize, which is conceptually incorrect since not just TARGET_DIR but also HOST_DIR is "regenerated" on a subsequent 'make' when everything was already built (i.e. only target-finalize is run). This can easily be fixed, by using the same hook as cmake uses, i.e. TOOLCHAIN_POST_INSTALL_STAGING_HOOKS. Note that actually even for cmake, TOOLCHAIN_POST_INSTALL_STAGING_HOOKS is not the best hook to install a host file. A better hook would have been TOOLCHAIN_POST_INSTALL_HOOKS, but this triggers only for 'host' packages, and 'toolchain' is treated as a 'target' package. Also, the hook (and therefore also the definition of PKG_MESON_INSTALL_CROSS_CONF) is moved to pkg-meson.mk, again to make it more similar to how it's done for cmake. Otherwise check-package complains that the meson package is setting variables that don't start with MESON_. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-02-25 14:11:46 -07:00
> $(HOST_DIR)/etc/meson/cross-compilation.conf.in
sed $(call PKG_MESON_CROSSCONFIG_SED,TARGET_CFLAGS,TARGET_CXXFLAGS,TARGET_LDFLAGS,TARGET_FCFLAGS) \
package/meson: install cross-compilation.conf during toolchain install package/meson installs a cross-compilation.conf file in $(HOST_DIR)/etc/meson, via TARGET_FINALIZE_HOOKS. package/pkg-cmake.mk installs a toolchainfile.cmake in $(HOST_DIR)/share/buildroot, via TOOLCHAIN_POST_INSTALL_STAGING_HOOKS. Both files have a similar concept, they describe some flags/paths needed for compilation using respective build systems. One difference is that the meson file is added for external compilation, from the SDK, while the cmake file is used internally in Buildroot. The 'problem' of using TARGET_FINALIZE_HOOKS for the meson file, is that it installs a 'host' file from target-finalize, which is conceptually incorrect since not just TARGET_DIR but also HOST_DIR is "regenerated" on a subsequent 'make' when everything was already built (i.e. only target-finalize is run). This can easily be fixed, by using the same hook as cmake uses, i.e. TOOLCHAIN_POST_INSTALL_STAGING_HOOKS. Note that actually even for cmake, TOOLCHAIN_POST_INSTALL_STAGING_HOOKS is not the best hook to install a host file. A better hook would have been TOOLCHAIN_POST_INSTALL_HOOKS, but this triggers only for 'host' packages, and 'toolchain' is treated as a 'target' package. Also, the hook (and therefore also the definition of PKG_MESON_INSTALL_CROSS_CONF) is moved to pkg-meson.mk, again to make it more similar to how it's done for cmake. Otherwise check-package complains that the meson package is setting variables that don't start with MESON_. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-02-25 14:11:46 -07:00
> $(HOST_DIR)/etc/meson/cross-compilation.conf
endef
package/pkg-meson: ensure the global cross-compilation.conf file is correct Currently, the cross-compilation.conf installed in $(HOST_DIR)/etc/meson/cross-compilation.conf for use by the SDK is generated in a post-install-staging hook of the toolchain package. With per-package directory support enabled, this means that the generated cross-compilation.conf contains references to the per-package directory of the toolchain/ package, which is not want we want: [binaries] c = '/home/thomas/projets/buildroot/output/per-package/toolchain/host/bin/arm-linux-gcc' cpp = '/home/thomas/projets/buildroot/output/per-package/toolchain/host/bin/arm-linux-g++' ar = '/home/thomas/projets/buildroot/output/per-package/toolchain/host/bin/arm-linux-ar' strip = '/home/thomas/projets/buildroot/output/per-package/toolchain/host/bin/arm-linux-strip' pkgconfig = '/home/thomas/projets/buildroot/output/per-package/toolchain/host/usr/bin/pkg-config' So instead, we generate this file in TOOLCHAIN_TARGET_FINALIZE_HOOKS, so that the global paths are used: [binaries] c = '/home/thomas/projets/buildroot/output/host/bin/arm-linux-gcc' cpp = '/home/thomas/projets/buildroot/output/host/bin/arm-linux-g++' ar = '/home/thomas/projets/buildroot/output/host/bin/arm-linux-ar' strip = '/home/thomas/projets/buildroot/output/host/bin/arm-linux-strip' pkgconfig = '/home/thomas/projets/buildroot/output/host/usr/bin/pkg-config' Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Reviewed-by: Peter Seiderer <ps.report@gmx.net> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2019-12-04 08:02:25 -07:00
TOOLCHAIN_TARGET_FINALIZE_HOOKS += PKG_MESON_INSTALL_CROSS_CONF