[Buildroot] [PATCH 0/2] Meson: new build system

[Buildroot] [PATCH 0/2] Meson: new build system

[Eric Le Bihan]

This small patch series provides a new build system: Meson.

It is a rework of the package formerly known as "python-meson", with the
following changes:

 - removed comments about file being generated in cross-compilation
   configuration file.
 - removed reference to "exe_wrapper" in cross-compilation configuration file.
 - removed installation of exe_wrapper.
 - removed dependency on host-qemu.

Eric Le Bihan (2):
  meson: new package
  docs/manual: document meson-based packages

 docs/manual/adding-packages-meson.txt   | 84 +++++++++++++++++++++++++++++++++
 docs/manual/adding-packages.txt         |  2 +
 package/meson/cross-compilation.conf.in | 17 +++++++
 package/meson/meson.hash                |  2 +
 package/meson/meson.mk                  | 31 ++++++++++++
 5 files changed, 136 insertions(+)
 create mode 100644 docs/manual/adding-packages-meson.txt
 create mode 100644 package/meson/cross-compilation.conf.in
 create mode 100644 package/meson/meson.hash
 create mode 100644 package/meson/meson.mk

--
2.4.11

[Buildroot] [PATCH 1/2] meson: new package

[Eric Le Bihan]

This new package provides the host variant of the Meson Build System, an
open source build system meant to be both extremely fast, and as user
friendly as possible.

More precisely, Meson creates configuration files for the Ninja build
system.

Besides building Meson, it generates a configuration file
("$(HOST_DIR)/etc/meson/cross-compilation.conf") to be used when
cross-compiling a Meson-based project.

Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
---
 package/meson/cross-compilation.conf.in | 17 +++++++++++++++++
 package/meson/meson.hash                |  2 ++
 package/meson/meson.mk                  | 31 +++++++++++++++++++++++++++++++
 3 files changed, 50 insertions(+)
 create mode 100644 package/meson/cross-compilation.conf.in
 create mode 100644 package/meson/meson.hash
 create mode 100644 package/meson/meson.mk

diff --git a/package/meson/cross-compilation.conf.in b/package/meson/cross-compilation.conf.in
new file mode 100644
index 0000000..33fa001
--- /dev/null
+++ b/package/meson/cross-compilation.conf.in
@@ -0,0 +1,17 @@
+# Note: in Meson terminology, what Buildroot calls the "host" system is the
+# "build" system and the "target" system is called the "host" system.
+
+[host_machine]
+system = 'linux'
+cpu_family ='@TARGET_ARCH@'
+cpu = 'generic'
+endian = '@TARGET_ENDIAN@'
+
+[properties]
+
+[binaries]
+c = '@TARGET_CROSS at gcc'
+cpp = '@TARGET_CROSS at g++'
+ar = '@TARGET_CROSS at ar'
+strip = '@TARGET_CROSS at strip'
+pkgconfig = '@HOST_DIR@/usr/bin/pkg-config'
diff --git a/package/meson/meson.hash b/package/meson/meson.hash
new file mode 100644
index 0000000..3a9ac2a
--- /dev/null
+++ b/package/meson/meson.hash
@@ -0,0 +1,2 @@
+# Locally generated
+sha256 372c18e40ffc3fe101f4ab48e8077f048dd774eaf4e87bbea3221908fca74835 meson-0.32.0.tar.gz
diff --git a/package/meson/meson.mk b/package/meson/meson.mk
new file mode 100644
index 0000000..8b95a6f
--- /dev/null
+++ b/package/meson/meson.mk
@@ -0,0 +1,31 @@
+################################################################################
+#
+# meson
+#
+################################################################################
+
+MESON_VERSION = 0.32.0
+MESON_SITE = $(call github,mesonbuild,meson,$(MESON_VERSION))
+MESON_LICENSE = Apache-2.0
+MESON_LICENSE_FILES = COPYING
+MESON_SETUP_TYPE = setuptools
+
+HOST_MESON_DEPENDENCIES = host-ninja
+HOST_MESON_NEEDS_HOST_PYTHON = python3
+
+HOST_MESON_TARGET_ENDIAN = $(shell echo $(BR2_ENDIAN) | tr 'A-Z' 'a-z')
+
+define HOST_MESON_INSTALL_CROSS_CONF
+	$(INSTALL) -D -m 0644 package/meson/cross-compilation.conf.in \
+		$(HOST_DIR)/etc/meson/cross-compilation.conf
+	$(SED) 's;@TARGET_CROSS@;$(TARGET_CROSS);g' \
+		-e 's;@TARGET_ARCH@;$(ARCH);g' \
+		-e 's;@TARGET_ENDIAN@;$(HOST_MESON_TARGET_ENDIAN);g' \
+		-e 's;@HOST_DIR@;$(HOST_DIR);g' \
+		$(HOST_DIR)/etc/meson/cross-compilation.conf
+endef
+
+HOST_MESON_POST_INSTALL_HOOKS += \
+	HOST_MESON_INSTALL_CROSS_CONF
+
+$(eval $(host-python-package))
-- 
2.4.11

[Buildroot] [PATCH 2/2] docs/manual: document meson-based packages

[Eric Le Bihan]

Add instructions for adding a package which uses the Meson build system.

Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
---
 docs/manual/adding-packages-meson.txt | 84 +++++++++++++++++++++++++++++++++++
 docs/manual/adding-packages.txt       |  2 +
 2 files changed, 86 insertions(+)
 create mode 100644 docs/manual/adding-packages-meson.txt

diff --git a/docs/manual/adding-packages-meson.txt b/docs/manual/adding-packages-meson.txt
new file mode 100644
index 0000000..85457b7
--- /dev/null
+++ b/docs/manual/adding-packages-meson.txt
@@ -0,0 +1,84 @@
+// -*- mode:doc; -*-
+// vim: set syntax=asciidoc:
+
+=== Integration of Meson-based packages
+
+[[meson-package-tutorial]]
+
+==== +meson-package+ tutorial
+
+http://mesonbuild.com[Meson] is an open source build system meant to be both
+extremely fast, and, even more importantly, as user friendly as possible.
+
+Buildroot does not (yet) provide a dedicated package infrastructure for
+meson-based packages. So, we will explain how to write a +.mk+ file for such a
+package. Let's start with an example:
+
+------------------------------
+01: ################################################################################
+02: #
+03: # foo
+04: #
+05: ################################################################################
+06:
+07: FOO_VERSION = 1.0
+08: FOO_SOURCE = foo-$(FOO_VERSION).tar.gz
+09: FOO_SITE = http://www.foosoftware.org/download
+10: FOO_LICENSE = GPLv3+
+11: FOO_LICENSE_FILES = COPYING
+12:
+13: FOO_DEPENDENCIES = host-meson host-pkgconf bar
+14:
+15: ifeq ($(BR2_ENABLE_DEBUG),y)
+16: FOO_MESON_MODE = debug
+17: else
+18: FOO_MESON_MODE = release
+19: endif
+20:
+21: FOO_MESON_OPTS += \
+22: 	--prefix=/usr \
+23: 	--buildtype $(FOO_MESON_MODE) \
+24: 	--cross-file $(HOST_DIR)/etc/meson/cross-compilation.conf
+25:
+26: define FOO_CONFIGURE_CMDS
+27: 	rm -rf $(@D)/build
+28: 	mkdir -p $(@D)/build
+29: 	$(TARGET_MAKE_ENV) meson.py $(FOO_MESON_OPTS) $(@D) $(@D)/build
+30: endef
+31:
+32: define FOO_BUILD_CMDS
+33: 	$(TARGET_MAKE_ENV) ninja -C $(@D)/build
+34: endef
+35:
+36: define FOO_INSTALL_TARGET_CMDS
+37: 	$(TARGET_MAKE_ENV) DESTDIR=$(TARGET_DIR) ninja -C $(@D)/build install
+38: endef
+39:
+40: $(eval $(generic-package))
+--------------------------------
+
+The Makefile starts with the definition of the standard variables for package
+declaration (lines 7 to 11).
+
+As seen in line 40, it is based on the
+xref:generic-package-tutorial[+generic-package+ infrastructure]. So, it defines
+the variables required by this particular infrastructure, where Meson and its
+companion tool, Ninja, are invoked:
+
+* +FOO_CONFIGURE_CMDS+: the build directory required by Meson is created, and
+  Meson is invoked to generate the Ninja build file. The options required to
+  configure the cross-compilation of the package are passed via +FOO_MESON_OPTS+.
+
+* +FOO_BUILD_CMDS+: Ninja is invoked to perform the build.
+
+* +FOO_INSTALL_TARGET_CMDS+: Ninja is invoked to install the files generated
+  during the build step.
+
+In order to have Meson available for the build, +FOO_DEPENDENCIES+ needs to
+contain +host-meson+. In the example, +host-pkgconf+ and +bar+ are also
+declared as dependencies because the Meson build file of +foo+ uses `pkg-config`
+to determine the compilation flags and libraries of package +bar+.
+
+To sum it up, to add a new meson-based package, the Makefile example can be
+copied verbatim then edited to replace all occurences of +FOO+ with the uppercase
+name of the new package and update the values of the standard variables.
diff --git a/docs/manual/adding-packages.txt b/docs/manual/adding-packages.txt
index 76f90c9..8b80a63 100644
--- a/docs/manual/adding-packages.txt
+++ b/docs/manual/adding-packages.txt
@@ -29,6 +29,8 @@ include::adding-packages-kconfig.txt[]
 
 include::adding-packages-rebar.txt[]
 
+include::adding-packages-meson.txt[]
+
 include::adding-packages-kernel-module.txt[]
 
 include::adding-packages-asciidoc.txt[]
-- 
2.4.11

[Buildroot] [PATCH 1/2] meson: new package

[Yann E. MORIN]

?ric, All,

On 2016-07-09 15:49 +0200, Eric Le Bihan spake thusly:
> This new package provides the host variant of the Meson Build System, an
> open source build system meant to be both extremely fast, and as user
> friendly as possible.
> 
> More precisely, Meson creates configuration files for the Ninja build
> system.
> 
> Besides building Meson, it generates a configuration file
> ("$(HOST_DIR)/etc/meson/cross-compilation.conf") to be used when
> cross-compiling a Meson-based project.
> 
> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> ---
>  package/meson/cross-compilation.conf.in | 17 +++++++++++++++++
>  package/meson/meson.hash                |  2 ++
>  package/meson/meson.mk                  | 31 +++++++++++++++++++++++++++++++
>  3 files changed, 50 insertions(+)
>  create mode 100644 package/meson/cross-compilation.conf.in
>  create mode 100644 package/meson/meson.hash
>  create mode 100644 package/meson/meson.mk
> 
> diff --git a/package/meson/cross-compilation.conf.in b/package/meson/cross-compilation.conf.in
> new file mode 100644
> index 0000000..33fa001
> --- /dev/null
> +++ b/package/meson/cross-compilation.conf.in
> @@ -0,0 +1,17 @@
> +# Note: in Meson terminology, what Buildroot calls the "host" system is the
> +# "build" system and the "target" system is called the "host" system.

Meson is using the correct terminology, the same as the autotools. It's
Buildroot that is /special/. ;-)

But yes, the comment is useful, to remove any ambiguity.

> +[host_machine]
> +system = 'linux'
> +cpu_family ='@TARGET_ARCH@'
> +cpu = 'generic'
> +endian = '@TARGET_ENDIAN@'
> +
> +[properties]

This properties section is empty. Can we do without it?

> +[binaries]
> +c = '@TARGET_CROSS at gcc'
> +cpp = '@TARGET_CROSS at g++'
> +ar = '@TARGET_CROSS at ar'
> +strip = '@TARGET_CROSS at strip'
> +pkgconfig = '@HOST_DIR@/usr/bin/pkg-config'
> diff --git a/package/meson/meson.hash b/package/meson/meson.hash
> new file mode 100644
> index 0000000..3a9ac2a
> --- /dev/null
> +++ b/package/meson/meson.hash
> @@ -0,0 +1,2 @@
> +# Locally generated
> +sha256 372c18e40ffc3fe101f4ab48e8077f048dd774eaf4e87bbea3221908fca74835 meson-0.32.0.tar.gz
> diff --git a/package/meson/meson.mk b/package/meson/meson.mk
> new file mode 100644
> index 0000000..8b95a6f
> --- /dev/null
> +++ b/package/meson/meson.mk
> @@ -0,0 +1,31 @@
> +################################################################################
> +#
> +# meson
> +#
> +################################################################################
> +
> +MESON_VERSION = 0.32.0
> +MESON_SITE = $(call github,mesonbuild,meson,$(MESON_VERSION))
> +MESON_LICENSE = Apache-2.0
> +MESON_LICENSE_FILES = COPYING
> +MESON_SETUP_TYPE = setuptools
> +
> +HOST_MESON_DEPENDENCIES = host-ninja
> +HOST_MESON_NEEDS_HOST_PYTHON = python3
> +
> +HOST_MESON_TARGET_ENDIAN = $(shell echo $(BR2_ENDIAN) | tr 'A-Z' 'a-z')
> +
> +define HOST_MESON_INSTALL_CROSS_CONF
> +	$(INSTALL) -D -m 0644 package/meson/cross-compilation.conf.in \
> +		$(HOST_DIR)/etc/meson/cross-compilation.conf
> +	$(SED) 's;@TARGET_CROSS@;$(TARGET_CROSS);g' \
> +		-e 's;@TARGET_ARCH@;$(ARCH);g' \
> +		-e 's;@TARGET_ENDIAN@;$(HOST_MESON_TARGET_ENDIAN);g' \
> +		-e 's;@HOST_DIR@;$(HOST_DIR);g' \

There is a reason I don;t like this $(SED): the first -e is implicit,
and so the code is not obvious.

> +		$(HOST_DIR)/etc/meson/cross-compilation.conf

Also, I would do it in a single pass:

    mkdir -p $(HOST_DIR)/etc/meson
    sed -e 's;@TARGET_CROSS@;$(TARGET_CROSS);g' \
        -e blabla \
        $(MESON_PKGDIR)/cross-compilation.conf.in \
        >$(HOST_DIR)/etc/meson/cross-compilation.conf

And then I'd be happy because there would be no implicit '-e'! :-)

But wait yet a bit more for others to express their preferences... ;-)

> +endef
> +
> +HOST_MESON_POST_INSTALL_HOOKS += \
> +	HOST_MESON_INSTALL_CROSS_CONF

No need for a continuation line, it all fits on a single line.

Regards,
Yann E. MORIN.

> +$(eval $(host-python-package))
> -- 
> 2.4.11
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

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

[Buildroot] [PATCH 1/2] meson: new package

[Yann E. MORIN]

?ric, All,

On 2016-07-09 15:49 +0200, Eric Le Bihan spake thusly:
> This new package provides the host variant of the Meson Build System, an
> open source build system meant to be both extremely fast, and as user
> friendly as possible.
> 
> More precisely, Meson creates configuration files for the Ninja build
> system.
> 
> Besides building Meson, it generates a configuration file
> ("$(HOST_DIR)/etc/meson/cross-compilation.conf") to be used when
> cross-compiling a Meson-based project.

OK, so I've done a review on this package, because it is not far from
being good.

However, I wonder how much we should have it *now* in Buildroot.

As you said as a reply to my previous review, there are not many
packages that use the meson buildsystem, and that you did not plan on
providing one in the foreseeable future.

What was your interest in adding meson in Buildroot, if you do not have
at least one package to submit that uses it?

Host packages that are not used by any target package, and that have no
entry in Kconfig, will never be exercised by the autobuilders, so we
won't be able to catch any build failure. Also, they are prone to
bit-rot, because they are not used, and thus breakage is never caught,
and thus no one fixes them.

In other words: why would we, in Buildroot mainstream, add this host
package, right now?

Regards,
Yann E. MORIN.

> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> ---
>  package/meson/cross-compilation.conf.in | 17 +++++++++++++++++
>  package/meson/meson.hash                |  2 ++
>  package/meson/meson.mk                  | 31 +++++++++++++++++++++++++++++++
>  3 files changed, 50 insertions(+)
>  create mode 100644 package/meson/cross-compilation.conf.in
>  create mode 100644 package/meson/meson.hash
>  create mode 100644 package/meson/meson.mk
> 
> diff --git a/package/meson/cross-compilation.conf.in b/package/meson/cross-compilation.conf.in
> new file mode 100644
> index 0000000..33fa001
> --- /dev/null
> +++ b/package/meson/cross-compilation.conf.in
> @@ -0,0 +1,17 @@
> +# Note: in Meson terminology, what Buildroot calls the "host" system is the
> +# "build" system and the "target" system is called the "host" system.
> +
> +[host_machine]
> +system = 'linux'
> +cpu_family ='@TARGET_ARCH@'
> +cpu = 'generic'
> +endian = '@TARGET_ENDIAN@'
> +
> +[properties]
> +
> +[binaries]
> +c = '@TARGET_CROSS at gcc'
> +cpp = '@TARGET_CROSS at g++'
> +ar = '@TARGET_CROSS at ar'
> +strip = '@TARGET_CROSS at strip'
> +pkgconfig = '@HOST_DIR@/usr/bin/pkg-config'
> diff --git a/package/meson/meson.hash b/package/meson/meson.hash
> new file mode 100644
> index 0000000..3a9ac2a
> --- /dev/null
> +++ b/package/meson/meson.hash
> @@ -0,0 +1,2 @@
> +# Locally generated
> +sha256 372c18e40ffc3fe101f4ab48e8077f048dd774eaf4e87bbea3221908fca74835 meson-0.32.0.tar.gz
> diff --git a/package/meson/meson.mk b/package/meson/meson.mk
> new file mode 100644
> index 0000000..8b95a6f
> --- /dev/null
> +++ b/package/meson/meson.mk
> @@ -0,0 +1,31 @@
> +################################################################################
> +#
> +# meson
> +#
> +################################################################################
> +
> +MESON_VERSION = 0.32.0
> +MESON_SITE = $(call github,mesonbuild,meson,$(MESON_VERSION))
> +MESON_LICENSE = Apache-2.0
> +MESON_LICENSE_FILES = COPYING
> +MESON_SETUP_TYPE = setuptools
> +
> +HOST_MESON_DEPENDENCIES = host-ninja
> +HOST_MESON_NEEDS_HOST_PYTHON = python3
> +
> +HOST_MESON_TARGET_ENDIAN = $(shell echo $(BR2_ENDIAN) | tr 'A-Z' 'a-z')
> +
> +define HOST_MESON_INSTALL_CROSS_CONF
> +	$(INSTALL) -D -m 0644 package/meson/cross-compilation.conf.in \
> +		$(HOST_DIR)/etc/meson/cross-compilation.conf
> +	$(SED) 's;@TARGET_CROSS@;$(TARGET_CROSS);g' \
> +		-e 's;@TARGET_ARCH@;$(ARCH);g' \
> +		-e 's;@TARGET_ENDIAN@;$(HOST_MESON_TARGET_ENDIAN);g' \
> +		-e 's;@HOST_DIR@;$(HOST_DIR);g' \
> +		$(HOST_DIR)/etc/meson/cross-compilation.conf
> +endef
> +
> +HOST_MESON_POST_INSTALL_HOOKS += \
> +	HOST_MESON_INSTALL_CROSS_CONF
> +
> +$(eval $(host-python-package))
> -- 
> 2.4.11
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

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

[Buildroot] [PATCH 2/2] docs/manual: document meson-based packages

[Yann E. MORIN]

?ric, All,

On 2016-07-09 15:49 +0200, Eric Le Bihan spake thusly:
> Add instructions for adding a package which uses the Meson build system.
> 
> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> ---
>  docs/manual/adding-packages-meson.txt | 84 +++++++++++++++++++++++++++++++++++
>  docs/manual/adding-packages.txt       |  2 +
>  2 files changed, 86 insertions(+)
>  create mode 100644 docs/manual/adding-packages-meson.txt
> 
> diff --git a/docs/manual/adding-packages-meson.txt b/docs/manual/adding-packages-meson.txt
> new file mode 100644
> index 0000000..85457b7
> --- /dev/null
> +++ b/docs/manual/adding-packages-meson.txt
> @@ -0,0 +1,84 @@
> +// -*- mode:doc; -*-
> +// vim: set syntax=asciidoc:
> +
> +=== Integration of Meson-based packages
> +
> +[[meson-package-tutorial]]
> +
> +==== +meson-package+ tutorial
> +
> +http://mesonbuild.com[Meson] is an open source build system meant to be both
> +extremely fast, and, even more importantly, as user friendly as possible.
> +
> +Buildroot does not (yet) provide a dedicated package infrastructure for
> +meson-based packages.

So why not provide one? A new infra is not trivial to write, indeed, but
given your example, the meson-package does not look like it is a complex
one to write (see below).

However, considering that we have no package that use meson yet, and
that you do not plan on sending one shortly, what's the point in having
either an infra or even this documentation?

> So, we will explain how to write a +.mk+ file for such a
> +package. Let's start with an example:
> +
> +------------------------------
> +01: ################################################################################
> +02: #
> +03: # foo
> +04: #
> +05: ################################################################################
> +06:
> +07: FOO_VERSION = 1.0
> +08: FOO_SOURCE = foo-$(FOO_VERSION).tar.gz
> +09: FOO_SITE = http://www.foosoftware.org/download
> +10: FOO_LICENSE = GPLv3+
> +11: FOO_LICENSE_FILES = COPYING
> +12:
> +13: FOO_DEPENDENCIES = host-meson host-pkgconf bar
> +14:
> +15: ifeq ($(BR2_ENABLE_DEBUG),y)
> +16: FOO_MESON_MODE = debug
> +17: else
> +18: FOO_MESON_MODE = release
> +19: endif
> +20:
> +21: FOO_MESON_OPTS += \
> +22: 	--prefix=/usr \
> +23: 	--buildtype $(FOO_MESON_MODE) \
> +24: 	--cross-file $(HOST_DIR)/etc/meson/cross-compilation.conf
> +25:
> +26: define FOO_CONFIGURE_CMDS
> +27: 	rm -rf $(@D)/build
> +28: 	mkdir -p $(@D)/build
> +29: 	$(TARGET_MAKE_ENV) meson.py $(FOO_MESON_OPTS) $(@D) $(@D)/build
> +30: endef
> +31:
> +32: define FOO_BUILD_CMDS
> +33: 	$(TARGET_MAKE_ENV) ninja -C $(@D)/build
> +34: endef
> +35:
> +36: define FOO_INSTALL_TARGET_CMDS
> +37: 	$(TARGET_MAKE_ENV) DESTDIR=$(TARGET_DIR) ninja -C $(@D)/build install
> +38: endef

It really looks very easy to write such an infra (totally untested, and
for taget packages only, assuming no host package wil use meson):

    define inner-meson-package

    ifndef $(2)_CONFIGURE_CMDS
    define $(2)_CONFIGURE_CMDS
        mkdir -p $$(@D)/build
        $$(TARGET_MAKE_ENV) meson.py \
            --prefix=/usr \
            --buildtype $$(if $$(BR2_ENABLE_DEBUG),debug,release) \
            --cross-file $$(HOST_DIR)/etc/meson/cross-compilation.conf \
            $$($(2)_CONF_OPTS) \
            $$(@D) \
            $$(@D)/build
    endef
    endif

    ifndef $(2)_BUILD_CMDS
    define $(2)_BUILD_CMDS
        $$(TARGET_MAKE_ENV) $$($(2)_MAKE_ENV) \
        ninja -C $$(@D)/build
    endef
    endif

    ifndef $(2)_INSTALL_STAGING_CMDS
    define $(2)_INSTALL_STAGING_CMDS
        $$(TARGET_MAKE_ENV) $$($(2)_MAKE_ENV) DESTDIR=$$(STAGING_DIR) \
        ninja -C $(@D)/build install
    endif
    endif

    ifndef $(2)_INSTALL_TARGET_CMDS
    define $(2)_INSTALL_TARGET_CMDS
        $$(TARGET_MAKE_ENV) $$($(2)_MAKE_ENV) DESTDIR=$$(TARGET_DIR) \
        ninja -C $(@D)/build install
    endif
    endif

    $(call inner-generic-package,$(1),$(2),$(3),$(4))

    endef # inner-meson-package

    meson-package = $(call inner-meson-package,$(pkgname),$(call UPPERCASE,$(pkgname)),$(call UPPERCASE,$(pkgname)),target)

Look at the existing infras for how they handle the host variants.

Again, totally untested as I wrote it directly in this mail...

Regards,
Yann E. MORIN.

> +40: $(eval $(generic-package))
> +--------------------------------
> +
> +The Makefile starts with the definition of the standard variables for package
> +declaration (lines 7 to 11).
> +
> +As seen in line 40, it is based on the
> +xref:generic-package-tutorial[+generic-package+ infrastructure]. So, it defines
> +the variables required by this particular infrastructure, where Meson and its
> +companion tool, Ninja, are invoked:
> +
> +* +FOO_CONFIGURE_CMDS+: the build directory required by Meson is created, and
> +  Meson is invoked to generate the Ninja build file. The options required to
> +  configure the cross-compilation of the package are passed via +FOO_MESON_OPTS+.
> +
> +* +FOO_BUILD_CMDS+: Ninja is invoked to perform the build.
> +
> +* +FOO_INSTALL_TARGET_CMDS+: Ninja is invoked to install the files generated
> +  during the build step.
> +
> +In order to have Meson available for the build, +FOO_DEPENDENCIES+ needs to
> +contain +host-meson+. In the example, +host-pkgconf+ and +bar+ are also
> +declared as dependencies because the Meson build file of +foo+ uses `pkg-config`
> +to determine the compilation flags and libraries of package +bar+.
> +
> +To sum it up, to add a new meson-based package, the Makefile example can be
> +copied verbatim then edited to replace all occurences of +FOO+ with the uppercase
> +name of the new package and update the values of the standard variables.
> diff --git a/docs/manual/adding-packages.txt b/docs/manual/adding-packages.txt
> index 76f90c9..8b80a63 100644
> --- a/docs/manual/adding-packages.txt
> +++ b/docs/manual/adding-packages.txt
> @@ -29,6 +29,8 @@ include::adding-packages-kconfig.txt[]
>  
>  include::adding-packages-rebar.txt[]
>  
> +include::adding-packages-meson.txt[]
> +
>  include::adding-packages-kernel-module.txt[]
>  
>  include::adding-packages-asciidoc.txt[]
> -- 
> 2.4.11
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

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

[Buildroot] [PATCH 1/2] meson: new package

[Eric Le Bihan]

Hi!

Le Sun, 17 Jul 2016 18:11:35 +0200,
"Yann E. MORIN" <yann.morin.1998@free.fr> a ?crit :

> On 2016-07-09 15:49 +0200, Eric Le Bihan spake thusly:
> > This new package provides the host variant of the Meson Build
> > System, an open source build system meant to be both extremely
> > fast, and as user friendly as possible.
> > 
> > More precisely, Meson creates configuration files for the Ninja
> > build system.
> > 
> > Besides building Meson, it generates a configuration file
> > ("$(HOST_DIR)/etc/meson/cross-compilation.conf") to be used when
> > cross-compiling a Meson-based project.
> > 
> > Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> > ---
> >  package/meson/cross-compilation.conf.in | 17 +++++++++++++++++
> >  package/meson/meson.hash                |  2 ++
> >  package/meson/meson.mk                  | 31
> > +++++++++++++++++++++++++++++++ 3 files changed, 50 insertions(+)
> >  create mode 100644 package/meson/cross-compilation.conf.in
> >  create mode 100644 package/meson/meson.hash
> >  create mode 100644 package/meson/meson.mk
> > 
> > diff --git a/package/meson/cross-compilation.conf.in
> > b/package/meson/cross-compilation.conf.in new file mode 100644
> > index 0000000..33fa001
> > --- /dev/null
> > +++ b/package/meson/cross-compilation.conf.in
> > @@ -0,0 +1,17 @@
> > +# Note: in Meson terminology, what Buildroot calls the "host"
> > system is the +# "build" system and the "target" system is called
> > the "host" system.  
> 
> Meson is using the correct terminology, the same as the autotools.
> It's Buildroot that is /special/. ;-)
> 
> But yes, the comment is useful, to remove any ambiguity.
> 
> > +[host_machine]
> > +system = 'linux'
> > +cpu_family ='@TARGET_ARCH@'
> > +cpu = 'generic'
> > +endian = '@TARGET_ENDIAN@'
> > +
> > +[properties]  
> 
> This properties section is empty. Can we do without it?

No. Otherwise Meson will complain. I informed the author about this.

> > +[binaries]
> > +c = '@TARGET_CROSS at gcc'
> > +cpp = '@TARGET_CROSS at g++'
> > +ar = '@TARGET_CROSS at ar'
> > +strip = '@TARGET_CROSS at strip'
> > +pkgconfig = '@HOST_DIR@/usr/bin/pkg-config'
> > diff --git a/package/meson/meson.hash b/package/meson/meson.hash
> > new file mode 100644
> > index 0000000..3a9ac2a
> > --- /dev/null
> > +++ b/package/meson/meson.hash
> > @@ -0,0 +1,2 @@
> > +# Locally generated
> > +sha256
> > 372c18e40ffc3fe101f4ab48e8077f048dd774eaf4e87bbea3221908fca74835
> > meson-0.32.0.tar.gz diff --git a/package/meson/meson.mk
> > b/package/meson/meson.mk new file mode 100644 index 0000000..8b95a6f
> > --- /dev/null
> > +++ b/package/meson/meson.mk
> > @@ -0,0 +1,31 @@
> > +################################################################################
> > +#
> > +# meson
> > +#
> > +################################################################################
> > +
> > +MESON_VERSION = 0.32.0
> > +MESON_SITE = $(call github,mesonbuild,meson,$(MESON_VERSION))
> > +MESON_LICENSE = Apache-2.0
> > +MESON_LICENSE_FILES = COPYING
> > +MESON_SETUP_TYPE = setuptools
> > +
> > +HOST_MESON_DEPENDENCIES = host-ninja
> > +HOST_MESON_NEEDS_HOST_PYTHON = python3
> > +
> > +HOST_MESON_TARGET_ENDIAN = $(shell echo $(BR2_ENDIAN) | tr 'A-Z'
> > 'a-z') +
> > +define HOST_MESON_INSTALL_CROSS_CONF
> > +	$(INSTALL) -D -m 0644
> > package/meson/cross-compilation.conf.in \
> > +		$(HOST_DIR)/etc/meson/cross-compilation.conf
> > +	$(SED) 's;@TARGET_CROSS@;$(TARGET_CROSS);g' \
> > +		-e 's;@TARGET_ARCH@;$(ARCH);g' \
> > +		-e
> > 's;@TARGET_ENDIAN@;$(HOST_MESON_TARGET_ENDIAN);g' \
> > +		-e 's;@HOST_DIR@;$(HOST_DIR);g' \  
> 
> There is a reason I don;t like this $(SED): the first -e is implicit,
> and so the code is not obvious.
> 
> > +		$(HOST_DIR)/etc/meson/cross-compilation.conf  
> 
> Also, I would do it in a single pass:
> 
>     mkdir -p $(HOST_DIR)/etc/meson
>     sed -e 's;@TARGET_CROSS@;$(TARGET_CROSS);g' \
>         -e blabla \
>         $(MESON_PKGDIR)/cross-compilation.conf.in \
>         >$(HOST_DIR)/etc/meson/cross-compilation.conf  
> 
> And then I'd be happy because there would be no implicit '-e'! :-)
> 
> But wait yet a bit more for others to express their preferences... ;-)

I've always been confused by the heterogeneous use of $(SED) and 'sed
-e' in the various Makefiles. I thought that $(SED) was the preferred
way, because this variable may hide a non-standard path for the sed
program (besides the hidden '-e'). If there is no such thing, then I'll
gladly use 'sed -e'.

> > +endef
> > +
> > +HOST_MESON_POST_INSTALL_HOOKS += \
> > +	HOST_MESON_INSTALL_CROSS_CONF  
> 
> No need for a continuation line, it all fits on a single line.

OK.

Thanks for the review.

Regards,

-- 
ELB

[Buildroot] [PATCH 1/2] meson: new package

[Eric Le Bihan]

Hi!

Le Sun, 17 Jul 2016 18:23:25 +0200,
"Yann E. MORIN" <yann.morin.1998@free.fr> a ?crit :

> On 2016-07-09 15:49 +0200, Eric Le Bihan spake thusly:
> > This new package provides the host variant of the Meson Build
> > System, an open source build system meant to be both extremely
> > fast, and as user friendly as possible.
> > 
> > More precisely, Meson creates configuration files for the Ninja
> > build system.
> > 
> > Besides building Meson, it generates a configuration file
> > ("$(HOST_DIR)/etc/meson/cross-compilation.conf") to be used when
> > cross-compiling a Meson-based project.  
> 
> OK, so I've done a review on this package, because it is not far from
> being good.

Thanks again for the insightful review.
 
> However, I wonder how much we should have it *now* in Buildroot.
> 
> As you said as a reply to my previous review, there are not many
> packages that use the meson buildsystem, and that you did not plan on
> providing one in the foreseeable future.
> 
> What was your interest in adding meson in Buildroot, if you do not
> have at least one package to submit that uses it?

IHMO, besides providing packages for programs to be run on embedded
devices, Buildroot should also provide tools for developing for such
devices: compilers, tools to generate flash images, debuggers and of
course build systems such as Meson.

It is true that Meson is relatively young and has a small user base
ATM, but as it is relatively easy to use and tries to handle
cross-compilation from the start, it may generate attraction (or not!).

But the same applies to the Rust series I also posted. This series
provides the Rust compiler and Cargo, the package manager, but no
target package depending on them. This new language is branded as being
oriented towards system programming and the compiler can generate code
for ARM and MIPS, which shows it is meant to be used for developing for
embedded devices.

Some users may be glad to have support for these tools out-of-the-box
in Buildroot, even though they are not developing programs to be
packaged for upstream. This is why I submitted this patch series.

> Host packages that are not used by any target package, and that have
> no entry in Kconfig, will never be exercised by the autobuilders, so
> we won't be able to catch any build failure. Also, they are prone to
> bit-rot, because they are not used, and thus breakage is never caught,
> and thus no one fixes them.

True. Even though host packages may only be built for x86, they may have
some dependencies between themselves that may break.

From what I understand the only host packages which are allowed to
appear in the "host utilities" configuration menu are the tools that
may be invoked by user scripts. These ones will be exercised by
the autobuilders, right?

Maybe other packages such as exotic/new compilers and build
systems should also be allowed, in order to be tested and to inform the
user that Buildroot provides them...

Regards,

-- 
ELB

[Buildroot] [PATCH 2/2] docs/manual: document meson-based packages

[Thomas Petazzoni]

Hello,

On Sun, 17 Jul 2016 18:37:24 +0200, Yann E. MORIN wrote:

> > +Buildroot does not (yet) provide a dedicated package infrastructure for
> > +meson-based packages.  
> 
> So why not provide one? A new infra is not trivial to write, indeed, but
> given your example, the meson-package does not look like it is a complex
> one to write (see below).
> 
> However, considering that we have no package that use meson yet, and
> that you do not plan on sending one shortly, what's the point in having
> either an infra or even this documentation?

I prefer to have an infrastructure once we have a few packages that
actually use meson. Until it is the case, I prefer to not have a
package infrastructure for this, especially since using generic-package
for Meson packages remains pretty simple, according to Eric's
documentation.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/2] meson: new package

[Arnout Vandecappelle]

On 18-07-16 10:57, Eric Le Bihan wrote:
> Hi!
> 
> Le Sun, 17 Jul 2016 18:23:25 +0200,
> "Yann E. MORIN" <yann.morin.1998@free.fr> a ?crit :
[snip]
>> However, I wonder how much we should have it *now* in Buildroot.
>>
>> As you said as a reply to my previous review, there are not many
>> packages that use the meson buildsystem, and that you did not plan on
>> providing one in the foreseeable future.
>>
>> What was your interest in adding meson in Buildroot, if you do not
>> have at least one package to submit that uses it?
> 
> IHMO, besides providing packages for programs to be run on embedded
> devices, Buildroot should also provide tools for developing for such
> devices: compilers, tools to generate flash images, debuggers and of
> course build systems such as Meson.

 Well, we have to draw the line somewhere. Currently, we clearly draw the line
at build systems. We don't allow users to use autoreconf, scons, cmake, ...
externally. Well, they can use it if they select a package that happens to use
these build systems, but there is no user-selectable option to enable e.g.
host-cmake.

 We discussed it here at the Buildroot developer meeting, and the general
agreement is that we should only introduce this build system when we have a
package that actually uses it.

 Until then, users can just install meson on their host. As you write, it's
pretty simple to use for cross-compilation.


> It is true that Meson is relatively young and has a small user base
> ATM, but as it is relatively easy to use and tries to handle
> cross-compilation from the start, it may generate attraction (or not!).
> 
> But the same applies to the Rust series I also posted. This series
> provides the Rust compiler and Cargo, the package manager, but no
> target package depending on them. This new language is branded as being
> oriented towards system programming and the compiler can generate code
> for ARM and MIPS, which shows it is meant to be used for developing for
> embedded devices.

 I'll reply to that independently. It's different because rust is really doing
cross-compilation.


> Some users may be glad to have support for these tools out-of-the-box
> in Buildroot, even though they are not developing programs to be
> packaged for upstream. This is why I submitted this patch series.
> 
>> Host packages that are not used by any target package, and that have
>> no entry in Kconfig, will never be exercised by the autobuilders, so
>> we won't be able to catch any build failure. Also, they are prone to
>> bit-rot, because they are not used, and thus breakage is never caught,
>> and thus no one fixes them.
> 
> True. Even though host packages may only be built for x86, they may have
> some dependencies between themselves that may break.
> 
> From what I understand the only host packages which are allowed to
> appear in the "host utilities" configuration menu are the tools that
> may be invoked by user scripts. These ones will be exercised by
> the autobuilders, right?
> 
> Maybe other packages such as exotic/new compilers and build
> systems should also be allowed, in order to be tested and to inform the
> user that Buildroot provides them...

 New compilers yes (again, after discussion here at the Developer Meeting), but
build systems no.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF