[Buildroot] allow build infrastructure to pick up installed meson tool

[Buildroot] allow build infrastructure to pick up installed meson tool

[Norbert Lange]

This is v3 of the patchset, only patch 1 got modifications.

Patch 1 will install a cross-compilation.conf as part of the toolchain
target, removing this logic from the meson package.

Patch 2 + Patch 3 allow picking up meson + ninja from the system,
this functionality is currently disabled.

Patch 4 moves some common functionality of the support tool
handling into a helper script.

[v2->v3]
-   rebase
-   support overriding [C,CXX,LD]FLAGS in package
-   place most logic into a HOST_MESON_CROSSCONFIG_SED variable
-   further refactoring and simplification

[Buildroot] [PATCH 1/4] package/pkg-meson: move crosscompilation support out of package

[Norbert Lange]

install the cross-compilation.conf file when setting up the
staging area, not as part of host-meson.
This allows external usage of the buildroot toolchain through meson.

Remove a few variables, as they were only used to communicate between
meson package and pkg-meson.

Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
 package/meson/meson.mk                        | 60 ------------
 package/pkg-meson.mk                          | 92 +++++++++++++++----
 .../misc}/cross-compilation.conf.in           |  0
 3 files changed, 72 insertions(+), 80 deletions(-)
 rename {package/meson => support/misc}/cross-compilation.conf.in (100%)

diff --git a/package/meson/meson.mk b/package/meson/meson.mk
index a664c55f55..435f8d338e 100644
--- a/package/meson/meson.mk
+++ b/package/meson/meson.mk
@@ -13,64 +13,4 @@ MESON_SETUP_TYPE = setuptools
 HOST_MESON_DEPENDENCIES = host-ninja
 HOST_MESON_NEEDS_HOST_PYTHON = python3
 
-HOST_MESON_TARGET_ENDIAN = $(call LOWERCASE,$(BR2_ENDIAN))
-HOST_MESON_TARGET_CPU = $(GCC_TARGET_CPU)
-
-# https://mesonbuild.com/Reference-tables.html#cpu-families
-ifeq ($(BR2_arcle)$(BR2_arceb),y)
-HOST_MESON_TARGET_CPU_FAMILY = arc
-else ifeq ($(BR2_arm)$(BR2_armeb),y)
-HOST_MESON_TARGET_CPU_FAMILY = arm
-else ifeq ($(BR2_aarch64)$(BR2_aarch64_be),y)
-HOST_MESON_TARGET_CPU_FAMILY = aarch64
-else ifeq ($(BR2_i386),y)
-HOST_MESON_TARGET_CPU_FAMILY = x86
-else ifeq ($(BR2_mips)$(BR2_mipsel),y)
-HOST_MESON_TARGET_CPU_FAMILY = mips
-else ifeq ($(BR2_mips64)$(BR2_mips64el),y)
-HOST_MESON_TARGET_CPU_FAMILY = mips64
-else ifeq ($(BR2_powerpc),y)
-HOST_MESON_TARGET_CPU_FAMILY = ppc
-else ifeq ($(BR2_powerpc64)$(BR2_powerpc64le),y)
-HOST_MESON_TARGET_CPU_FAMILY = ppc64
-else ifeq ($(BR2_riscv),y)
-HOST_MESON_TARGET_CPU_FAMILY = riscv64
-else ifeq ($(BR2_sparc),y)
-HOST_MESON_TARGET_CPU_FAMILY = sparc
-else ifeq ($(BR2_sparc64),y)
-HOST_MESON_TARGET_CPU_FAMILY = sparc64
-else ifeq ($(BR2_x86_64),y)
-HOST_MESON_TARGET_CPU_FAMILY = x86_64
-else
-HOST_MESON_TARGET_CPU_FAMILY = $(ARCH)
-endif
-
-HOST_MESON_SED_CFLAGS = $(if $(strip $(TARGET_CFLAGS)),`printf '"%s"$(comma) ' $(TARGET_CFLAGS)`)
-HOST_MESON_SED_LDFLAGS = $(if $(strip $(TARGET_LDFLAGS)),`printf '"%s"$(comma) ' $(TARGET_LDFLAGS)`)
-HOST_MESON_SED_CXXFLAGS = $(if $(strip $(TARGET_CXXFLAGS)),`printf '"%s"$(comma) ' $(TARGET_CXXFLAGS)`)
-
-# 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 HOST_MESON_INSTALL_CROSS_CONF
-	mkdir -p $(HOST_DIR)/etc/meson
-	sed -e "s%@TARGET_CROSS@%$(TARGET_CROSS)%g" \
-	    -e "s%@TARGET_ARCH@%$(HOST_MESON_TARGET_CPU_FAMILY)%g" \
-	    -e "s%@TARGET_CPU@%$(HOST_MESON_TARGET_CPU)%g" \
-	    -e "s%@TARGET_ENDIAN@%$(HOST_MESON_TARGET_ENDIAN)%g" \
-	    -e "s%@TARGET_CFLAGS@%$(HOST_MESON_SED_CFLAGS)@PKG_TARGET_CFLAGS@%g" \
-	    -e "s%@TARGET_LDFLAGS@%$(HOST_MESON_SED_LDFLAGS)@PKG_TARGET_CFLAGS@%g" \
-	    -e "s%@TARGET_CXXFLAGS@%$(HOST_MESON_SED_CXXFLAGS)@PKG_TARGET_CFLAGS@%g" \
-	    -e "s%@HOST_DIR@%$(HOST_DIR)%g" \
-	    $(HOST_MESON_PKGDIR)/cross-compilation.conf.in \
-	    > $(HOST_DIR)/etc/meson/cross-compilation.conf.in
-	sed -e "s%@PKG_TARGET_CFLAGS@%%g" \
-	    -e "s%@PKG_TARGET_LDFLAGS@%%g" \
-	    -e "s%@PKG_TARGET_CXXFLAGS@%%g" \
-	    $(HOST_DIR)/etc/meson/cross-compilation.conf.in \
-	    > $(HOST_DIR)/etc/meson/cross-compilation.conf
-endef
-
-TARGET_FINALIZE_HOOKS += HOST_MESON_INSTALL_CROSS_CONF
-
 $(eval $(host-python-package))
diff --git a/package/pkg-meson.mk b/package/pkg-meson.mk
index 184a22a44a..2756fb7856 100644
--- a/package/pkg-meson.mk
+++ b/package/pkg-meson.mk
@@ -57,32 +57,18 @@ $(2)_NINJA_ENV		?=
 ifndef $(2)_CONFIGURE_CMDS
 ifeq ($(4),target)
 
-$(2)_CFLAGS ?= $$(TARGET_CFLAGS)
-$(2)_LDFLAGS ?= $$(TARGET_LDFLAGS)
-$(2)_CXXFLAGS ?= $$(TARGET_CXXFLAGS)
-
-$(2)_MESON_SED_CFLAGS = $$(if $$(strip $$($(2)_CFLAGS)),`printf '"%s"$$(comma) ' $$($(2)_CFLAGS)`)
-$(2)_MESON_SED_LDFLAGS = $$(if $$(strip $$($(2)_LDFLAGS)),`printf '"%s"$$(comma) ' $$($(2)_LDFLAGS)`)
-$(2)_MESON_SED_CXXFLAGS = $$(if $$(strip $$($(2)_CXXFLAGS)),`printf '"%s"$$(comma) ' $$($(2)_CXXFLAGS)`)
-
 # Configure package for target
 #
 #
 define $(2)_CONFIGURE_CMDS
 	rm -rf $$($$(PKG)_SRCDIR)/build
 	mkdir -p $$($$(PKG)_SRCDIR)/build
-	sed -e "s%@TARGET_CROSS@%$$(TARGET_CROSS)%g" \
-	    -e "s%@TARGET_ARCH@%$$(HOST_MESON_TARGET_CPU_FAMILY)%g" \
-	    -e "s%@TARGET_CPU@%$$(GCC_TARGET_CPU)%g" \
-	    -e "s%@TARGET_ENDIAN@%$$(call LOWERCASE,$$(BR2_ENDIAN))%g" \
-	    -e "s%@TARGET_CFLAGS@%$$($(2)_MESON_SED_CFLAGS)%g" \
-	    -e "s%@TARGET_LDFLAGS@%$$($(2)_MESON_SED_LDFLAGS)%g" \
-	    -e "s%@TARGET_CXXFLAGS@%$$($(2)_MESON_SED_CXXFLAGS)%g" \
-	    -e "s%@HOST_DIR@%$$(HOST_DIR)%g" \
-	    $$(foreach x,$$($(2)_MESON_EXTRA_BINARIES), \
-	        -e "/^\[binaries\]$$$$/s:$$$$:\n$$(x):" \
-	    ) \
-	    package/meson/cross-compilation.conf.in \
+	sed $$(foreach x,$$($(2)_MESON_EXTRA_BINARIES), \
+                -e "/^\[binaries\]$$$$/s:$$$$:\n$$(x):" \
+        ) \
+        $$(call HOST_MESON_CROSSCONFIG_SED,$$(if $$($(2)_CFLAGS),$(2)_CFLAGS,TARGET_CFLAGS), \
+                $$(if $$($(2)_CXXFLAGS),$(2)_CXXFLAGS,TARGET_CXXFLAGS), \
+                $$(if $$($(2)_LDFLAGS),$(2)_LDFLAGS,TARGET_LDFLAGS)) \
 	    > $$($$(PKG)_SRCDIR)/build/cross-compilation.conf
 	PATH=$$(BR_PATH) $$($$(PKG)_CONF_ENV) $$(MESON) \
 		--prefix=/usr \
@@ -178,3 +164,69 @@ endef
 
 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)
+
+################################################################################
+# Generation of the Messon compile flags and cross-compilation file
+################################################################################
+
+# https://mesonbuild.com/Reference-tables.html#cpu-families
+ifeq ($(BR2_arcle)$(BR2_arceb),y)
+HOST_MESON_TARGET_CPU_FAMILY = arc
+else ifeq ($(BR2_arm)$(BR2_armeb),y)
+HOST_MESON_TARGET_CPU_FAMILY = arm
+else ifeq ($(BR2_aarch64)$(BR2_aarch64_be),y)
+HOST_MESON_TARGET_CPU_FAMILY = aarch64
+else ifeq ($(BR2_i386),y)
+HOST_MESON_TARGET_CPU_FAMILY = x86
+else ifeq ($(BR2_mips)$(BR2_mipsel),y)
+HOST_MESON_TARGET_CPU_FAMILY = mips
+else ifeq ($(BR2_mips64)$(BR2_mips64el),y)
+HOST_MESON_TARGET_CPU_FAMILY = mips64
+else ifeq ($(BR2_powerpc),y)
+HOST_MESON_TARGET_CPU_FAMILY = ppc
+else ifeq ($(BR2_powerpc64)$(BR2_powerpc64le),y)
+HOST_MESON_TARGET_CPU_FAMILY = ppc64
+else ifeq ($(BR2_riscv),y)
+HOST_MESON_TARGET_CPU_FAMILY = riscv64
+else ifeq ($(BR2_sparc),y)
+HOST_MESON_TARGET_CPU_FAMILY = sparc
+else ifeq ($(BR2_sparc64),y)
+HOST_MESON_TARGET_CPU_FAMILY = sparc64
+else ifeq ($(BR2_x86_64),y)
+HOST_MESON_TARGET_CPU_FAMILY = x86_64
+else
+HOST_MESON_TARGET_CPU_FAMILY = $(ARCH)
+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).
+# Aruments are variable containing cflags, cxxflags, ldflags.
+define HOST_MESON_CROSSCONFIG_SED
+        -e "s%@TARGET_CROSS@%$(TARGET_CROSS)%g" \
+        -e "s%@TARGET_ARCH@%$(HOST_MESON_TARGET_CPU_FAMILY)%g" \
+        -e "s%@TARGET_CPU@%$(GCC_TARGET_CPU)%g" \
+        -e "s%@TARGET_ENDIAN@%$(call LOWERCASE,$(BR2_ENDIAN))%g" \
+        -e "s%@TARGET_CFLAGS@%$(patsubst %,\"%\"$(comma),$($(strip $(1))))%g" \
+        -e "s%@TARGET_LDFLAGS@%$(patsubst %,\"%\"$(comma),$($(strip $(3))))%g" \
+        -e "s%@TARGET_CXXFLAGS@%$(patsubst %,\"%\"$(comma),$($(strip $(2))))%g" \
+        -e "s%@HOST_DIR@%$(HOST_DIR)%g" \
+        $(TOPDIR)/support/misc/cross-compilation.conf.in
+endef
+
+# 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 TOOLCHAIN_MESON_INSTALL_FILES
+	mkdir -p $(HOST_DIR)/etc/meson
+	sed -e "s%@TARGET_CFLAGS@%$(patsubst %,\"%\"$(comma),$(TARGET_CFLAGS))@PKG_TARGET_CFLAGS@%g" \
+	    -e "s%@TARGET_LDFLAGS@%$(patsubst %,\"%\"$(comma),$(TARGET_LDFLAGS))@PKG_TARGET_CFLAGS@%g" \
+	    -e "s%@TARGET_CXXFLAGS@%$(patsubst %,\"%\"$(comma),$(TARGET_CXXFLAGS))@PKG_TARGET_CFLAGS@%g" \
+	    $(call HOST_MESON_CROSSCONFIG_SED) \
+	    > $(HOST_DIR)/etc/meson/cross-compilation.conf.in
+	sed $(call HOST_MESON_CROSSCONFIG_SED,TARGET_CFLAGS,TARGET_CXXFLAGS,TARGET_LDFLAGS) \
+	    > $(HOST_DIR)/etc/meson/cross-compilation.conf
+endef
+
+TOOLCHAIN_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_MESON_INSTALL_FILES
+TOOLCHAIN_INSTALL_STAGING = YES
diff --git a/package/meson/cross-compilation.conf.in b/support/misc/cross-compilation.conf.in
similarity index 100%
rename from package/meson/cross-compilation.conf.in
rename to support/misc/cross-compilation.conf.in
-- 
2.23.0

[Buildroot] [PATCH 2/4] prepare build infrastructure to pick up installed meson tool

[Norbert Lange]

Automatically check for an available meson tool,
and use it as long as the version is fitting.

Using a system provided meson is not an official supported
option, hence this is currently disabled.
use of the system provided meson can be enforced with:

   make ... BR2_MESON_VERSION_MIN=0

Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
 package/pkg-meson.mk                     |  4 +--
 support/dependencies/check-host-meson.mk | 15 ++++++++
 support/dependencies/check-host-meson.sh | 45 ++++++++++++++++++++++++
 3 files changed, 62 insertions(+), 2 deletions(-)
 create mode 100644 support/dependencies/check-host-meson.mk
 create mode 100755 support/dependencies/check-host-meson.sh

diff --git a/package/pkg-meson.mk b/package/pkg-meson.mk
index 2756fb7856..3a66ab8f5a 100644
--- a/package/pkg-meson.mk
+++ b/package/pkg-meson.mk
@@ -25,7 +25,7 @@
 # $(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
+MESON		= PYTHONNOUSERSITE=y $(BR2_MESON)
 NINJA		= PYTHONNOUSERSITE=y $(HOST_DIR)/bin/ninja
 NINJA_OPTS	= $(if $(VERBOSE),-v) -j$(PARALLEL_JOBS)

@@ -99,7 +99,7 @@ endef
 endif
 endif

-$(2)_DEPENDENCIES += host-meson
+$(2)_DEPENDENCIES += $(BR2_MESON_HOST_DEPENDENCY)

 #
 # Build step. Only define it if not already defined by the package .mk
diff --git a/support/dependencies/check-host-meson.mk b/support/dependencies/check-host-meson.mk
new file mode 100644
index 0000000000..fbe0b7d7aa
--- /dev/null
+++ b/support/dependencies/check-host-meson.mk
@@ -0,0 +1,15 @@
+# Set this to a valid version like  0.49, depending on the highest minimum
+# version required by any of the packages bundled in Buildroot.
+# An empty version will never match a system executable
+#
+# BR2_MESON_VERSION_MIN = 0.49
+
+BR2_MESON_CANDIDATES ?= meson
+BR2_MESON ?= $(call suitable-host-package,meson,\
+	$(BR2_MESON_VERSION_MIN) $(BR2_MESON_CANDIDATES))
+ifeq ($(BR2_MESON),)
+BR2_MESON = $(HOST_DIR)/bin/meson
+BR2_MESON_HOST_DEPENDENCY = host-meson host-ninja
+else
+BR2_MESON_HOST_DEPENDENCY = host-ninja
+endif
diff --git a/support/dependencies/check-host-meson.sh b/support/dependencies/check-host-meson.sh
new file mode 100755
index 0000000000..62746822cc
--- /dev/null
+++ b/support/dependencies/check-host-meson.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+# prevent shift error
+[ $# -ge 2 ] && [ -n "$1" ] || exit 1
+
+split_version() {
+    local VARPREFIX
+    local NUMBERS
+    local major
+    local minor
+
+    VARPREFIX=$1
+    NUMBERS=$2
+
+    major=${NUMBERS%%\.*}
+    NUMBERS=${NUMBERS#$major}; NUMBERS=${NUMBERS#\.}
+    minor=${NUMBERS%%\.*}
+    NUMBERS=${NUMBERS#$minor}; NUMBERS=${NUMBERS#\.}
+
+    # ensure that missing values are 0
+    eval "${VARPREFIX}_major=\$major; ${VARPREFIX}_minor=\$((minor + 0)); ${VARPREFIX}_bugfix=\$((NUMBERS + 0));"
+}
+
+split_version req "$1"
+
+shift
+
+for candidate; do
+
+    # Try to locate the candidate. Discard it if not located.
+    tool=$(which "${candidate}" 2>/dev/null)
+    [ -n "${tool}" ] || continue
+
+    split_version cur "$("${tool}" --version)"
+
+    [ -n "${cur_major}" -a "${cur_major}" -ge "${req_major}" ] || continue
+    [ "${cur_major}" -gt "${req_major}" ] || [ "${cur_minor}" -ge "${req_minor}" ] || continue
+    [ "${cur_minor}" -gt "${req_minor}" ] || [ "${cur_bugfix}" -ge "${req_bugfix}" ] || continue
+
+    echo "${tool}"
+    exit
+done
+
+# echo nothing: no suitable tool found
+exit 1
--
2.23.0

[Buildroot] [PATCH 3/4] prepare build infrastructure to pick up installed ninja tool

[Norbert Lange]

The only notable use is as dependency from meson,
since using the system installed meson is not officially
supported, netiher is using a system installed ninja.

a user can force the use of the system installed ninja with

   make graph-depends BR2_NINJA_VERSION_MIN=0

Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
 package/meson/meson.mk                   |  1 -
 package/pkg-meson.mk                     |  2 +-
 support/dependencies/check-host-meson.mk |  4 +--
 support/dependencies/check-host-ninja.mk | 13 +++++++
 support/dependencies/check-host-ninja.sh | 45 ++++++++++++++++++++++++
 5 files changed, 61 insertions(+), 4 deletions(-)
 create mode 100644 support/dependencies/check-host-ninja.mk
 create mode 100755 support/dependencies/check-host-ninja.sh

diff --git a/package/meson/meson.mk b/package/meson/meson.mk
index 435f8d338e..98b816e2a7 100644
--- a/package/meson/meson.mk
+++ b/package/meson/meson.mk
@@ -10,7 +10,6 @@ MESON_LICENSE = Apache-2.0
 MESON_LICENSE_FILES = COPYING
 MESON_SETUP_TYPE = setuptools

-HOST_MESON_DEPENDENCIES = host-ninja
 HOST_MESON_NEEDS_HOST_PYTHON = python3

 $(eval $(host-python-package))
diff --git a/package/pkg-meson.mk b/package/pkg-meson.mk
index 3a66ab8f5a..aa1ef15240 100644
--- a/package/pkg-meson.mk
+++ b/package/pkg-meson.mk
@@ -26,7 +26,7 @@
 # $HOME/.local/lib/python3.x/site-packages
 #
 MESON		= PYTHONNOUSERSITE=y $(BR2_MESON)
-NINJA		= PYTHONNOUSERSITE=y $(HOST_DIR)/bin/ninja
+NINJA		= PYTHONNOUSERSITE=y $(BR2_NINJA)
 NINJA_OPTS	= $(if $(VERBOSE),-v) -j$(PARALLEL_JOBS)

 ################################################################################
diff --git a/support/dependencies/check-host-meson.mk b/support/dependencies/check-host-meson.mk
index fbe0b7d7aa..fb07bea792 100644
--- a/support/dependencies/check-host-meson.mk
+++ b/support/dependencies/check-host-meson.mk
@@ -9,7 +9,7 @@ BR2_MESON ?= $(call suitable-host-package,meson,\
 	$(BR2_MESON_VERSION_MIN) $(BR2_MESON_CANDIDATES))
 ifeq ($(BR2_MESON),)
 BR2_MESON = $(HOST_DIR)/bin/meson
-BR2_MESON_HOST_DEPENDENCY = host-meson host-ninja
+BR2_MESON_HOST_DEPENDENCY = host-meson $(BR2_NINJA_HOST_DEPENDENCY)
 else
-BR2_MESON_HOST_DEPENDENCY = host-ninja
+BR2_MESON_HOST_DEPENDENCY = $(BR2_NINJA_HOST_DEPENDENCY)
 endif
diff --git a/support/dependencies/check-host-ninja.mk b/support/dependencies/check-host-ninja.mk
new file mode 100644
index 0000000000..09ee45ef1e
--- /dev/null
+++ b/support/dependencies/check-host-ninja.mk
@@ -0,0 +1,13 @@
+# Set this to a valid version like 1.8.2, depending on the highest
+# minimum version required by any of the packages bundled in Buildroot.
+# An empty version will never match a system executable
+#
+# BR2_NINJA_VERSION_MIN = 1.8.2
+
+BR2_NINJA_CANDIDATES ?= ninja
+BR2_NINJA ?= $(call suitable-host-package,ninja,\
+	$(BR2_NINJA_VERSION_MIN) $(BR2_NINJA_CANDIDATES))
+ifeq ($(BR2_NINJA),)
+BR2_NINJA = $(HOST_DIR)/bin/ninja
+BR2_NINJA_HOST_DEPENDENCY = host-ninja
+endif
diff --git a/support/dependencies/check-host-ninja.sh b/support/dependencies/check-host-ninja.sh
new file mode 100755
index 0000000000..62746822cc
--- /dev/null
+++ b/support/dependencies/check-host-ninja.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+# prevent shift error
+[ $# -ge 2 ] && [ -n "$1" ] || exit 1
+
+split_version() {
+    local VARPREFIX
+    local NUMBERS
+    local major
+    local minor
+
+    VARPREFIX=$1
+    NUMBERS=$2
+
+    major=${NUMBERS%%\.*}
+    NUMBERS=${NUMBERS#$major}; NUMBERS=${NUMBERS#\.}
+    minor=${NUMBERS%%\.*}
+    NUMBERS=${NUMBERS#$minor}; NUMBERS=${NUMBERS#\.}
+
+    # ensure that missing values are 0
+    eval "${VARPREFIX}_major=\$major; ${VARPREFIX}_minor=\$((minor + 0)); ${VARPREFIX}_bugfix=\$((NUMBERS + 0));"
+}
+
+split_version req "$1"
+
+shift
+
+for candidate; do
+
+    # Try to locate the candidate. Discard it if not located.
+    tool=$(which "${candidate}" 2>/dev/null)
+    [ -n "${tool}" ] || continue
+
+    split_version cur "$("${tool}" --version)"
+
+    [ -n "${cur_major}" -a "${cur_major}" -ge "${req_major}" ] || continue
+    [ "${cur_major}" -gt "${req_major}" ] || [ "${cur_minor}" -ge "${req_minor}" ] || continue
+    [ "${cur_minor}" -gt "${req_minor}" ] || [ "${cur_bugfix}" -ge "${req_bugfix}" ] || continue
+
+    echo "${tool}"
+    exit
+done
+
+# echo nothing: no suitable tool found
+exit 1
--
2.23.0

[Buildroot] [PATCH 4/4] support/dependencies: use a helper script for common checks

[Norbert Lange]

Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
 support/dependencies/check-host-cmake.sh | 47 +++---------------------
 support/dependencies/check-host-make.sh  | 39 +++-----------------
 support/dependencies/check-host-meson.sh | 44 ++--------------------
 support/dependencies/check-host-ninja.sh | 44 ++--------------------
 support/dependencies/versioncheck.sh     | 45 +++++++++++++++++++++++
 5 files changed, 61 insertions(+), 158 deletions(-)
 create mode 100755 support/dependencies/versioncheck.sh

diff --git a/support/dependencies/check-host-cmake.sh b/support/dependencies/check-host-cmake.sh
index fadeae9f6b..0699ddf571 100755
--- a/support/dependencies/check-host-cmake.sh
+++ b/support/dependencies/check-host-cmake.sh
@@ -1,45 +1,8 @@
 #!/bin/sh
 
-# prevent shift error
-[ $# -lt 2 ] && exit 1
+readversion() {
+	"$1" --version |
+		sed -r -e '/.* ([[:digit:]]+\.[[:digit:]]+).*$/!d;' -e 's//\1/'
+}
 
-major_min="${1%.*}"
-minor_min="${1#*.}"
-
-shift
-
-for candidate; do
-
-    # Try to locate the candidate. Discard it if not located.
-    cmake=`which "${candidate}" 2>/dev/null`
-    [ -n "${cmake}" ] || continue
-
-    # Extract version X.Y from versions in the form X.Y or X.Y.Z
-    # with X, Y and Z numbers with one or more digits each, e.g.
-    #   3.2     -> 3.2
-    #   3.2.3   -> 3.2
-    #   3.2.42  -> 3.2
-    #   3.10    -> 3.10
-    #   3.10.4  -> 3.10
-    #   3.10.42 -> 3.10
-    # Discard the candidate if no version can be obtained
-    version="$(${cmake} --version \
-               |sed -r -e '/.* ([[:digit:]]+\.[[:digit:]]+).*$/!d;' \
-                       -e 's//\1/'
-              )"
-    [ -n "${version}" ] || continue
-
-    major="${version%.*}"
-    minor="${version#*.}"
-
-    if [ ${major} -gt ${major_min} ]; then
-        echo "${cmake}"
-        exit
-    elif [ ${major} -eq ${major_min} -a ${minor} -ge ${minor_min} ]; then
-        echo "${cmake}"
-        exit
-    fi
-done
-
-# echo nothing: no suitable cmake found
-exit 1
+. "$(dirname "$(readlink -e "$0")")"/versioncheck.sh
diff --git a/support/dependencies/check-host-make.sh b/support/dependencies/check-host-make.sh
index 0de7e9f6fa..77bfc5123d 100755
--- a/support/dependencies/check-host-make.sh
+++ b/support/dependencies/check-host-make.sh
@@ -1,37 +1,8 @@
 #!/bin/sh
 
-# prevent shift error
-[ $# -lt 2 ] && exit 1
+readversion() {
+	"$1" --version 2>&1 |
+		sed -e 's/^.* \([0-9\.]\)/\1/g' -e 's/[-].*//g' -e '1q'
+}
 
-major_min="${1%.*}"
-minor_min="${1#*.}"
-
-shift
-
-# The host make program is already checked by dependencies.sh but we
-# want to check the version number even if Buildroot is able to use
-# GNU make >= 3.81 but some packages may require a more recent version.
-make="$1"
-
-# Output of 'make --version' examples:
-# GNU Make 4.2.1
-# GNU Make 4.0
-# GNU Make 3.81
-version=`$make --version 2>&1 | sed -e 's/^.* \([0-9\.]\)/\1/g' -e 's/[-\
-].*//g' -e '1q'`
-
-major=`echo "$version" | cut -d. -f1`
-minor=`echo "$version" | cut -d. -f2`
-
-if [ $major -lt $major_min ]; then
-	# echo nothing: no suitable make found
-	exit 1
-fi
-
-if [ $major -eq $major_min -a $minor -lt $minor_min ]; then
-	# echo nothing: no suitable make found
-	exit 1
-fi
-
-# valid
-echo $make
+. "$(dirname "$(readlink -e "$0")")"/versioncheck.sh
diff --git a/support/dependencies/check-host-meson.sh b/support/dependencies/check-host-meson.sh
index 62746822cc..bec7bf4505 100755
--- a/support/dependencies/check-host-meson.sh
+++ b/support/dependencies/check-host-meson.sh
@@ -1,45 +1,7 @@
 #!/bin/sh
 
-# prevent shift error
-[ $# -ge 2 ] && [ -n "$1" ] || exit 1
-
-split_version() {
-    local VARPREFIX
-    local NUMBERS
-    local major
-    local minor
-
-    VARPREFIX=$1
-    NUMBERS=$2
-
-    major=${NUMBERS%%\.*}
-    NUMBERS=${NUMBERS#$major}; NUMBERS=${NUMBERS#\.}
-    minor=${NUMBERS%%\.*}
-    NUMBERS=${NUMBERS#$minor}; NUMBERS=${NUMBERS#\.}
-
-    # ensure that missing values are 0
-    eval "${VARPREFIX}_major=\$major; ${VARPREFIX}_minor=\$((minor + 0)); ${VARPREFIX}_bugfix=\$((NUMBERS + 0));"
+readversion() {
+	"$1" --version
 }
 
-split_version req "$1"
-
-shift
-
-for candidate; do
-
-    # Try to locate the candidate. Discard it if not located.
-    tool=$(which "${candidate}" 2>/dev/null)
-    [ -n "${tool}" ] || continue
-
-    split_version cur "$("${tool}" --version)"
-
-    [ -n "${cur_major}" -a "${cur_major}" -ge "${req_major}" ] || continue
-    [ "${cur_major}" -gt "${req_major}" ] || [ "${cur_minor}" -ge "${req_minor}" ] || continue
-    [ "${cur_minor}" -gt "${req_minor}" ] || [ "${cur_bugfix}" -ge "${req_bugfix}" ] || continue
-
-    echo "${tool}"
-    exit
-done
-
-# echo nothing: no suitable tool found
-exit 1
+. "$(dirname "$(readlink -e "$0")")"/versioncheck.sh
diff --git a/support/dependencies/check-host-ninja.sh b/support/dependencies/check-host-ninja.sh
index 62746822cc..bec7bf4505 100755
--- a/support/dependencies/check-host-ninja.sh
+++ b/support/dependencies/check-host-ninja.sh
@@ -1,45 +1,7 @@
 #!/bin/sh
 
-# prevent shift error
-[ $# -ge 2 ] && [ -n "$1" ] || exit 1
-
-split_version() {
-    local VARPREFIX
-    local NUMBERS
-    local major
-    local minor
-
-    VARPREFIX=$1
-    NUMBERS=$2
-
-    major=${NUMBERS%%\.*}
-    NUMBERS=${NUMBERS#$major}; NUMBERS=${NUMBERS#\.}
-    minor=${NUMBERS%%\.*}
-    NUMBERS=${NUMBERS#$minor}; NUMBERS=${NUMBERS#\.}
-
-    # ensure that missing values are 0
-    eval "${VARPREFIX}_major=\$major; ${VARPREFIX}_minor=\$((minor + 0)); ${VARPREFIX}_bugfix=\$((NUMBERS + 0));"
+readversion() {
+	"$1" --version
 }
 
-split_version req "$1"
-
-shift
-
-for candidate; do
-
-    # Try to locate the candidate. Discard it if not located.
-    tool=$(which "${candidate}" 2>/dev/null)
-    [ -n "${tool}" ] || continue
-
-    split_version cur "$("${tool}" --version)"
-
-    [ -n "${cur_major}" -a "${cur_major}" -ge "${req_major}" ] || continue
-    [ "${cur_major}" -gt "${req_major}" ] || [ "${cur_minor}" -ge "${req_minor}" ] || continue
-    [ "${cur_minor}" -gt "${req_minor}" ] || [ "${cur_bugfix}" -ge "${req_bugfix}" ] || continue
-
-    echo "${tool}"
-    exit
-done
-
-# echo nothing: no suitable tool found
-exit 1
+. "$(dirname "$(readlink -e "$0")")"/versioncheck.sh
diff --git a/support/dependencies/versioncheck.sh b/support/dependencies/versioncheck.sh
new file mode 100755
index 0000000000..e606da87e4
--- /dev/null
+++ b/support/dependencies/versioncheck.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+# prevent shift error
+[ $# -ge 2 ] && [ -n "$1" ] || exit 1
+
+split_version() {
+	local VARPREFIX
+	local NUMBERS
+	local major
+	local minor
+
+	VARPREFIX=$1
+	NUMBERS=$2
+
+	major=${NUMBERS%%\.*}
+	NUMBERS=${NUMBERS#$major}; NUMBERS=${NUMBERS#\.}
+	minor=${NUMBERS%%\.*}
+	NUMBERS=${NUMBERS#$minor}; NUMBERS=${NUMBERS#\.}
+
+	# ensure that missing values are 0
+	eval "${VARPREFIX}_major=\$major; ${VARPREFIX}_minor=\$((minor + 0)); ${VARPREFIX}_bugfix=\$((NUMBERS + 0));"
+}
+
+split_version req "$1"
+
+shift
+
+for candidate; do
+
+	# Try to locate the candidate. Discard it if not located.
+	tool=$(which "${candidate}" 2>/dev/null)
+	[ -n "${tool}" ] || continue
+
+	split_version cur "$(readversion "${tool}")"
+
+	[ -n "${cur_major}" -a "${cur_major}" -ge "${req_major}" ] || continue
+	[ "${cur_major}" -gt "${req_major}" ] || [ "${cur_minor}" -ge "${req_minor}" ] || continue
+	[ "${cur_minor}" -gt "${req_minor}" ] || [ "${cur_bugfix}" -ge "${req_bugfix}" ] || continue
+
+	echo "${tool}"
+	exit
+done
+
+# echo nothing: no suitable tool found
+exit 1
-- 
2.23.0

[Buildroot] [PATCH 2/4] prepare build infrastructure to pick up installed meson tool

[Thomas Petazzoni]

Hello Norbert

On Wed, 16 Oct 2019 13:19:25 +0200
Norbert Lange <nolange79@gmail.com> wrote:

> Automatically check for an available meson tool,
> and use it as long as the version is fitting.
> 
> Using a system provided meson is not an official supported
> option, hence this is currently disabled.
> use of the system provided meson can be enforced with:
> 
>    make ... BR2_MESON_VERSION_MIN=0
> 
> Signed-off-by: Norbert Lange <nolange79@gmail.com>

Thanks for this, however I don't think we will ever merge this until a
system-provided meson can effectively be used.

What about working on merging
0001-Only-fix-RPATH-if-install_rpath-is-not-empty.patch to upstream
Meson, in this form or another form ? This would definitely pave the
way to using the system-provided Meson.

Another (more useful ?) thing to look at: is it possible to use the
system-provided Python for Meson and Ninja, when python3 is provided by
the system ? I think Meson and Ninja by themselves are not long at all
to build, and it would be a much more useful direction for this patch
series.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 2/4] prepare build infrastructure to pick up installed meson tool

[Norbert Lange]

Am Mi., 16. Okt. 2019 um 15:48 Uhr schrieb Thomas Petazzoni
<thomas.petazzoni@bootlin.com>:
>
> Hello Norbert
>
> On Wed, 16 Oct 2019 13:19:25 +0200
> Norbert Lange <nolange79@gmail.com> wrote:
>
> > Automatically check for an available meson tool,
> > and use it as long as the version is fitting.
> >
> > Using a system provided meson is not an official supported
> > option, hence this is currently disabled.
> > use of the system provided meson can be enforced with:
> >
> >    make ... BR2_MESON_VERSION_MIN=0
> >
> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
>
> Thanks for this, however I don't think we will ever merge this until a
> system-provided meson can effectively be used.

Well I do effectively use it, meson and its dependencies multiply my build-time,
builds systemd and my libfuse3 package fine.

Patch #1 is a freestanding improvement, I hope there arent issues with merging
at least that one?

> What about working on merging
> 0001-Only-fix-RPATH-if-install_rpath-is-not-empty.patch to upstream
> Meson, in this form or another form ? This would definitely pave the
> way to using the system-provided Meson.

I'm in no way involved with meson, AFAIK this was proposed for upstream already?

> Another (more useful ?) thing to look at: is it possible to use the
> system-provided Python for Meson and Ninja, when python3 is provided by
> the system ? I think Meson and Ninja by themselves are not long at all
> to build, and it would be a much more useful direction for this patch
> series.

Define "useful". The patches work correctly for me (tm), and I dont
use more than
1000 included packages that are useless for me (tm).
Even if meson is not ready (again: it is for me), then improving
buildroot ahead of it
causes no harm?

If I were cynical, Id say I prefer spending time porting packages to
CMake rather than trying to fix meson.

regards Norbert.

[Buildroot] [PATCH 2/4] prepare build infrastructure to pick up installed meson tool

[Yann E. MORIN]

Thomas, Norbert, All,

On 2019-10-16 15:48 +0200, Thomas Petazzoni spake thusly:
> On Wed, 16 Oct 2019 13:19:25 +0200
> Norbert Lange <nolange79@gmail.com> wrote:
> > Automatically check for an available meson tool,
> > and use it as long as the version is fitting.
> 
> Thanks for this, however I don't think we will ever merge this until a
> system-provided meson can effectively be used.

I do agreee with that.

However, I guess that what Norbert is trying to do, is to build their
own meson that they patched with our patch, thus achieving the
"system-provided meson is capable" status.

But if we're going that way for meson, why not do the same for all the
other host tools we do build? That would be totally unfeasible.

So, I am still not convinced by this feature, until we can at least
detect that a system-provided meson is capable, and that we can decide
by actually asking that meson (e.g. by checking the version, or dumping
its help for options, or whatevs...).

> What about working on merging
> 0001-Only-fix-RPATH-if-install_rpath-is-not-empty.patch to upstream
> Meson, in this form or another form ? This would definitely pave the
> way to using the system-provided Meson.
> 
> Another (more useful ?) thing to look at: is it possible to use the
> system-provided Python for Meson and Ninja, when python3 is provided by
> the system ? I think Meson and Ninja by themselves are not long at all
> to build, and it would be a much more useful direction for this patch
> series.

But then, it should be done very carefully: if the hot-python3 must
otherwise be built (because something else forcibly depends on it), then
our host-meson must also be using that host-python3 too, otherwise, we
could end up with a host-meson built with the system-provided python3
but run with our host-python3.

Regards,
Yann E. MORIN.

> Thanks!
> 
> Thomas
> -- 
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 2/4] prepare build infrastructure to pick up installed meson tool

[Norbert Lange]

Am Mi., 16. Okt. 2019 um 18:47 Uhr schrieb Yann E. MORIN
<yann.morin.1998@free.fr>:
>
> Thomas, Norbert, All,
>
> On 2019-10-16 15:48 +0200, Thomas Petazzoni spake thusly:
> > On Wed, 16 Oct 2019 13:19:25 +0200
> > Norbert Lange <nolange79@gmail.com> wrote:
> > > Automatically check for an available meson tool,
> > > and use it as long as the version is fitting.
> >
> > Thanks for this, however I don't think we will ever merge this until a
> > system-provided meson can effectively be used.
>
> I do agreee with that.
>
> However, I guess that what Norbert is trying to do, is to build their
> own meson that they patched with our patch, thus achieving the
> "system-provided meson is capable" status.

Actually I use meson from debian testing.

> But if we're going that way for meson, why not do the same for all the
> other host tools we do build? That would be totally unfeasible.

For those complicated or long to build its useful. You already do that for
CMake, several compressors and a few others.

> So, I am still not convinced by this feature, until we can at least
> detect that a system-provided meson is capable, and that we can decide
> by actually asking that meson (e.g. by checking the version, or dumping
> its help for options, or whatevs...).

Again, patch #1 is a freestanding cleanup, hope atleast that is clear
for merging?
And the patches never automatically use meson/ninja, but are helpful
if a user would decide to cut buildtime (in a scenario where the
system tools suffice).

What about if you just want to build a toolchain? I can use this
painless from CMake,
as the toolchain.cmake gets installed even if I dont build CMake or
have CMake installed.
I would want the same for meson.

> > What about working on merging
> > 0001-Only-fix-RPATH-if-install_rpath-is-not-empty.patch to upstream
> > Meson, in this form or another form ? This would definitely pave the
> > way to using the system-provided Meson.
> >
> > Another (more useful ?) thing to look at: is it possible to use the
> > system-provided Python for Meson and Ninja, when python3 is provided by
> > the system ? I think Meson and Ninja by themselves are not long at all
> > to build, and it would be a much more useful direction for this patch
> > series.
>
> But then, it should be done very carefully: if the hot-python3 must
> otherwise be built (because something else forcibly depends on it), then
> our host-meson must also be using that host-python3 too, otherwise, we
> could end up with a host-meson built with the system-provided python3
> but run with our host-python3.

Hmm, dont get why using system python is anything better than using cmake,
ninja or (a fixed/usable) meson from the system.

regards, Norbert

[Buildroot] [PATCH 2/4] prepare build infrastructure to pick up installed meson tool

[Thomas Petazzoni]

Hello,

On Wed, 16 Oct 2019 18:28:02 +0200
Norbert Lange <nolange79@gmail.com> wrote:

> > Thanks for this, however I don't think we will ever merge this until a
> > system-provided meson can effectively be used.  
> 
> Well I do effectively use it, meson and its dependencies multiply my build-time,
> builds systemd and my libfuse3 package fine.
> 
> Patch #1 is a freestanding improvement, I hope there arent issues with merging
> at least that one?

Yes, of course PATCH 1/4 is totally independent from this discussion,
and can/will be considered separately. I looked at it briefly, I
haven't made up my mind yet, but I agree it is completely separate.

> > What about working on merging
> > 0001-Only-fix-RPATH-if-install_rpath-is-not-empty.patch to upstream
> > Meson, in this form or another form ? This would definitely pave the
> > way to using the system-provided Meson.  
> 
> I'm in no way involved with meson, AFAIK this was proposed for upstream already?

You don't have to be involved with Meson to work on it. Many of us
regularly contribute patches to upstream projects without being
involved in any way with those projects.

> > Another (more useful ?) thing to look at: is it possible to use the
> > system-provided Python for Meson and Ninja, when python3 is provided by
> > the system ? I think Meson and Ninja by themselves are not long at all
> > to build, and it would be a much more useful direction for this patch
> > series.  
> 
> Define "useful". The patches work correctly for me (tm), and I dont
> use more than 1000 included packages that are useless for me (tm).
> Even if meson is not ready (again: it is for me), then improving
> buildroot ahead of it causes no harm?

Because today meson requires a Buildroot patch, and in fact what really
adds to the build time is not building host-meson or host-ninja, but
really the fact that it requires the build of host-python3. And Python
3.x is now widely available on most build machines. So the idea would
be, instead of relying on system-provided meson/ninja, to still build
our own meson/ninja, but really the system-provided python3.

> If I were cynical, Id say I prefer spending time porting packages to
> CMake rather than trying to fix meson.

I don't think the point of this discussion is to decide whether cmake,
meson or autotools, or whatever is the best build system.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 2/4] prepare build infrastructure to pick up installed meson tool

[Yann E. MORIN]

Norbert, Thomas, All,

On 2019-10-16 21:01 +0200, Thomas Petazzoni spake thusly:
> On Wed, 16 Oct 2019 18:28:02 +0200
> Norbert Lange <nolange79@gmail.com> wrote:
> > Well I do effectively use it, meson and its dependencies multiply my build-time,
> > builds systemd and my libfuse3 package fine.

So this had me wonder: why do you report that it works for you (and I am
ready to believe you), although we do have a patch that you are not
using?

Put in other words, I was wondering that, maybe, your report was an
indication that our patch was in fact no longer needed, in which case we
could drop it and would reconsider your proposal.

So I had to dig a bit on what this patch was doing (it is a relatively
simple patch), and why it was needed.

It turns out that the prupose of that patch is to ensure that a
host-meson-package that also uses a library installed by one of our
other host packages, keeps an RPATH to find that library (instead of not
finding it, or of finding the system-provided one).

This is nicely laid out in the git log for our patch:

    commit 5c939246a802c0ad9704dac1505105037542a1d3
    Author: Eric Le Bihan <eric.le.bihan.dev@free.fr>
    Date:   Sat Oct 27 19:59:22 2018 +0200

        meson: re-add patch for skipping RPATH fixing

        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 <eric.le.bihan.dev@free.fr>
        Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

So yes, ther are situations where using a system-provided meson _may_
work, but the generic case is that our patch is still required to ensure
that the situatiuon dexribed above still works.

Note that the only package in that situation in upstream Buildroot, is
libglib2, so if you don't have that, then you do not have the problem
this patch is solving.

So, with those explanations, I hope it is now clearer why we can't rely
on the system-provided meson.

Anyway, your proposal was interesting, if at least because it really
made us reconsider the usefulness of our patch.

> > > Another (more useful ?) thing to look at: is it possible to use the
> > > system-provided Python for Meson and Ninja, when python3 is provided by
> > > the system ? I think Meson and Ninja by themselves are not long at all
> > > to build, and it would be a much more useful direction for this patch
> > > series.  
> > Define "useful". The patches work correctly for me (tm), and I dont
> > use more than 1000 included packages that are useless for me (tm).
> > Even if meson is not ready (again: it is for me), then improving
> > buildroot ahead of it causes no harm?

The case "works for me" is not a valid reason, because as demonstrated
above, there are cases where it won't work.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 2/4] prepare build infrastructure to pick up installed meson tool

[Norbert Lange]

Am Mi., 16. Okt. 2019 um 21:01 Uhr schrieb Thomas Petazzoni
<thomas.petazzoni@bootlin.com>:
>
> Hello,
>
> On Wed, 16 Oct 2019 18:28:02 +0200
> Norbert Lange <nolange79@gmail.com> wrote:
>
> > > Thanks for this, however I don't think we will ever merge this until a
> > > system-provided meson can effectively be used.
> >
> > Well I do effectively use it, meson and its dependencies multiply my build-time,
> > builds systemd and my libfuse3 package fine.
> >
> > Patch #1 is a freestanding improvement, I hope there arent issues with merging
> > at least that one?
>
> Yes, of course PATCH 1/4 is totally independent from this discussion,
> and can/will be considered separately. I looked at it briefly, I
> haven't made up my mind yet, but I agree it is completely separate.
>
> > > What about working on merging
> > > 0001-Only-fix-RPATH-if-install_rpath-is-not-empty.patch to upstream
> > > Meson, in this form or another form ? This would definitely pave the
> > > way to using the system-provided Meson.
> >
> > I'm in no way involved with meson, AFAIK this was proposed for upstream already?
>
> You don't have to be involved with Meson to work on it. Many of us
> regularly contribute patches to upstream projects without being
> involved in any way with those projects.

I don't even know what the issue is, as I use the system meson without troubles,
I can however do the other part: prepare BR for using system meson
(in the hope that those issues will be sorted out sometime).

> > > Another (more useful ?) thing to look at: is it possible to use the
> > > system-provided Python for Meson and Ninja, when python3 is provided by
> > > the system ? I think Meson and Ninja by themselves are not long at all
> > > to build, and it would be a much more useful direction for this patch
> > > series.
> >
> > Define "useful". The patches work correctly for me (tm), and I dont
> > use more than 1000 included packages that are useless for me (tm).
> > Even if meson is not ready (again: it is for me), then improving
> > buildroot ahead of it causes no harm?
>
> Because today meson requires a Buildroot patch, and in fact what really
> adds to the build time is not building host-meson or host-ninja, but
> really the fact that it requires the build of host-python3. And Python
> 3.x is now widely available on most build machines. So the idea would
> be, instead of relying on system-provided meson/ninja, to still build
> our own meson/ninja, but really the system-provided python3.

I get that you prefer to build meson as only supported option, but why
exactly is there a big issue of
preparing a feature (that needs some arcane Variable overrides to enable).
I build my meson packages without any trouble (and got a email to rebase my
patch, so I don't think I am the only one).
With ninja its even worse as it only needs python for a bootstrap
*during build*,
ninja is actually stable and broadly available, means any newer
version will work.
Of course meson is currently the only realistic reason for pulling in
host-ninja.

All I am saying is that the decision to what tools can be picked from the system
seems arbitrary to me. Nowadays you would just use a container with the
tools prepared (could even use a patched meson).

> > If I were cynical, Id say I prefer spending time porting packages to
> > CMake rather than trying to fix meson.
>
> I don't think the point of this discussion is to decide whether cmake,
> meson or autotools, or whatever is the best build system.

Nope, but only one of these needs to be rebuilt every time in buildroot.

Regards, Norbert

[Buildroot] [PATCH 2/4] prepare build infrastructure to pick up installed meson tool

[Norbert Lange]

Am Mi., 16. Okt. 2019 um 22:16 Uhr schrieb Yann E. MORIN
<yann.morin.1998@free.fr>:
>
> Norbert, Thomas, All,
>
> On 2019-10-16 21:01 +0200, Thomas Petazzoni spake thusly:
> > On Wed, 16 Oct 2019 18:28:02 +0200
> > Norbert Lange <nolange79@gmail.com> wrote:
> > > Well I do effectively use it, meson and its dependencies multiply my build-time,
> > > builds systemd and my libfuse3 package fine.
>
> So this had me wonder: why do you report that it works for you (and I am
> ready to believe you), although we do have a patch that you are not
> using?
>
> Put in other words, I was wondering that, maybe, your report was an
> indication that our patch was in fact no longer needed, in which case we
> could drop it and would reconsider your proposal.
>
> So I had to dig a bit on what this patch was doing (it is a relatively
> simple patch), and why it was needed.
>
> It turns out that the prupose of that patch is to ensure that a
> host-meson-package that also uses a library installed by one of our
> other host packages, keeps an RPATH to find that library (instead of not
> finding it, or of finding the system-provided one).
>
> This is nicely laid out in the git log for our patch:
>
>     commit 5c939246a802c0ad9704dac1505105037542a1d3
>     Author: Eric Le Bihan <eric.le.bihan.dev@free.fr>
>     Date:   Sat Oct 27 19:59:22 2018 +0200
>
>         meson: re-add patch for skipping RPATH fixing
>
>         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 <eric.le.bihan.dev@free.fr>
>         Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
>
> So yes, ther are situations where using a system-provided meson _may_
> work, but the generic case is that our patch is still required to ensure
> that the situatiuon dexribed above still works.

Yes, you want to be able to build all packages in buildroot without issues.
My patch would not change that. You would need to set an variable
override to pick up the system meson/ninja.

If upstream is fixed and you are confident nothing breaks, just set
that variable
in check-host-meson.mk.
Work done now, tested by users at their own peril now, flipping the switch
later. Sounds not so outrageous for me?

> Note that the only package in that situation in upstream Buildroot, is
> libglib2, so if you don't have that, then you do not have the problem
> this patch is solving.
>
> So, with those explanations, I hope it is now clearer why we can't rely
> on the system-provided meson.

Not rely, but add an option that the user can pick up the system meson
if he dares to do so.

> Anyway, your proposal was interesting, if at least because it really
> made us reconsider the usefulness of our patch.
>
> > > > Another (more useful ?) thing to look at: is it possible to use the
> > > > system-provided Python for Meson and Ninja, when python3 is provided by
> > > > the system ? I think Meson and Ninja by themselves are not long at all
> > > > to build, and it would be a much more useful direction for this patch
> > > > series.
> > > Define "useful". The patches work correctly for me (tm), and I dont
> > > use more than 1000 included packages that are useless for me (tm).
> > > Even if meson is not ready (again: it is for me), then improving
> > > buildroot ahead of it causes no harm?
>
> The case "works for me" is not a valid reason, because as demonstrated
> above, there are cases where it won't work.

As reiterated above, unless you explicitly enable it, those patches will
NOT pick up system meson. "Works for me" means there is a valid reason
for having the option.

Regards, Norbert

[Buildroot] [PATCH 2/4] prepare build infrastructure to pick up installed meson tool

[Thomas Petazzoni]

Hello Norbert,

On Wed, 16 Oct 2019 22:31:24 +0200
Norbert Lange <nolange79@gmail.com> wrote:

> > So yes, ther are situations where using a system-provided meson _may_
> > work, but the generic case is that our patch is still required to ensure
> > that the situatiuon dexribed above still works.  
> 
> Yes, you want to be able to build all packages in buildroot without issues.
> My patch would not change that. You would need to set an variable
> override to pick up the system meson/ninja.

We don't want to have this code that is basically "dead" (because it can
only be enabled by tweaking those variables in the environment).

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 2/4] prepare build infrastructure to pick up installed meson tool

[Norbert Lange]

Am Mi., 16. Okt. 2019 um 23:08 Uhr schrieb Thomas Petazzoni
<thomas.petazzoni@bootlin.com>:
>
> Hello Norbert,
>
> On Wed, 16 Oct 2019 22:31:24 +0200
> Norbert Lange <nolange79@gmail.com> wrote:
>
> > > So yes, ther are situations where using a system-provided meson _may_
> > > work, but the generic case is that our patch is still required to ensure
> > > that the situatiuon dexribed above still works.
> >
> > Yes, you want to be able to build all packages in buildroot without issues.
> > My patch would not change that. You would need to set an variable
> > override to pick up the system meson/ninja.
>
> We don't want to have this code that is basically "dead" (because it can
> only be enabled by tweaking those variables in the environment).

Sure then, please look at the other patches and I will respin those you
deem useful

regards, Norbert