[Buildroot] [PATCH 0/2] improve virtual package infra

[Buildroot] [PATCH 0/2] improve virtual package infra

[Eric Le Bihan]

This patch series, intended for the -next branch, improves virtual package
infrastructure by:

- using make control functions in dependency check.
- adding a tutorial to the user manual.

Best regards,
ELB

Eric Le Bihan (2):
  infra: improve dependency check in virtual packages.
  manual: add virtual package tutorial.

 docs/manual/adding-packages-virtual.txt  |  102 ++++++++++++++++++++++++++++++
 docs/manual/adding-packages.txt          |    2 +
 package/luainterpreter/luainterpreter.mk |    6 ++
 package/opengl/libegl/libegl.mk          |    7 +-
 package/opengl/libgles/libgles.mk        |    7 +-
 package/opengl/libopenmax/libopenmax.mk  |    7 +-
 package/opengl/libopenvg/libopenvg.mk    |    7 +-
 package/powervr/powervr.mk               |    7 +-
 8 files changed, 125 insertions(+), 20 deletions(-)
 create mode 100644 docs/manual/adding-packages-virtual.txt

--
1.7.9.5

[Buildroot] [PATCH 1/2] infra: improve dependency check in virtual packages.

[Eric Le Bihan]

The current version of dependency check for virtual package <foo>
defines FOO_CONFIGURE_CMDS to print an error message if the
dependencies are not met.

This patch updates all the virtual packages to use the GNU Make control
function $(error text...) instead.

This makes the error happen at the beginning of the build, with a clearer
message.

Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
---
 package/luainterpreter/luainterpreter.mk |    6 ++++++
 package/opengl/libegl/libegl.mk          |    7 +++----
 package/opengl/libgles/libgles.mk        |    7 +++----
 package/opengl/libopenmax/libopenmax.mk  |    7 +++----
 package/opengl/libopenvg/libopenvg.mk    |    7 +++----
 package/powervr/powervr.mk               |    7 +++----
 6 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/package/luainterpreter/luainterpreter.mk b/package/luainterpreter/luainterpreter.mk
index c37d621..5443477 100644
--- a/package/luainterpreter/luainterpreter.mk
+++ b/package/luainterpreter/luainterpreter.mk
@@ -9,4 +9,10 @@ LUAINTERPRETER_DEPENDENCIES = $(call qstrip,$(BR2_PACKAGE_PROVIDES_LUA_INTERPRET
 
 LUAINTERPRETER_ABIVER = $(call qstrip,$(BR2_PACKAGE_LUAINTERPRETER_ABI_VERSION))
 
+ifeq ($(BR2_PACKAGE_HAS_LUA_INTERPRETER),y)
+ifeq ($(LUAINTERPRETER_DEPENDENCIES),)
+$(error No lua interpreter implementation selected. Configuration error.)
+endif
+endif
+
 $(eval $(generic-package))
diff --git a/package/opengl/libegl/libegl.mk b/package/opengl/libegl/libegl.mk
index b2b74f1..3311e50 100644
--- a/package/opengl/libegl/libegl.mk
+++ b/package/opengl/libegl/libegl.mk
@@ -7,11 +7,10 @@
 LIBEGL_SOURCE =
 LIBEGL_DEPENDENCIES = $(call qstrip,$(BR2_PACKAGE_PROVIDES_OPENGL_EGL))
 
+ifeq ($(BR2_PACKAGE_HAS_OPENGL_EGL),y)
 ifeq ($(LIBEGL_DEPENDENCIES),)
-define LIBEGL_CONFIGURE_CMDS
-	echo "No libEGL implementation selected. Configuration error."
-	exit 1
-endef
+$(error No libEGL implementation selected. Configuration error.)
+endif
 endif
 
 $(eval $(generic-package))
diff --git a/package/opengl/libgles/libgles.mk b/package/opengl/libgles/libgles.mk
index 0dcbaa7..7a07e37 100644
--- a/package/opengl/libgles/libgles.mk
+++ b/package/opengl/libgles/libgles.mk
@@ -7,11 +7,10 @@
 LIBGLES_SOURCE =
 LIBGLES_DEPENDENCIES = $(call qstrip,$(BR2_PACKAGE_PROVIDES_OPENGL_ES))
 
+ifeq ($(BR2_PACKAGE_HAS_OPENGL_ES),y)
 ifeq ($(LIBGLES_DEPENDENCIES),)
-define LIBGLES_CONFIGURE_CMDS
-	echo "No libGLES implementation selected. Configuration error."
-	exit 1
-endef
+$(error No libGLES implementation selected. Configuration error.)
+endif
 endif
 
 $(eval $(generic-package))
diff --git a/package/opengl/libopenmax/libopenmax.mk b/package/opengl/libopenmax/libopenmax.mk
index c4f1f71..a2bd23d 100644
--- a/package/opengl/libopenmax/libopenmax.mk
+++ b/package/opengl/libopenmax/libopenmax.mk
@@ -7,11 +7,10 @@
 LIBOPENMAX_SOURCE =
 LIBOPENMAX_DEPENDENCIES = $(call qstrip,$(BR2_PACKAGE_PROVIDES_OPENMAX))
 
+ifeq ($(BR2_PACKAGE_HAS_OPENMAX),y)
 ifeq ($(LIBOPENMAX_DEPENDENCIES),)
-define LIBOPENMAX_CONFIGURE_CMDS
-	echo "No libopenmax implementation selected. Configuration error."
-	exit 1
-endef
+$(error No libopenmax implementation selected. Configuration error.)
+endif
 endif
 
 $(eval $(generic-package))
diff --git a/package/opengl/libopenvg/libopenvg.mk b/package/opengl/libopenvg/libopenvg.mk
index ffd9d68..f81db5e 100644
--- a/package/opengl/libopenvg/libopenvg.mk
+++ b/package/opengl/libopenvg/libopenvg.mk
@@ -7,11 +7,10 @@
 LIBOPENVG_SOURCE =
 LIBOPENVG_DEPENDENCIES = $(call qstrip,$(BR2_PACKAGE_PROVIDES_OPENVG))
 
+ifeq ($(BR2_PACKAGE_HAS_OPENVG),y)
 ifeq ($(LIBOPENVG_DEPENDENCIES),)
-define LIBOPENVG_CONFIGURE_CMDS
-	echo "No libOpenVG implementation selected. Configuration error."
-	exit 1
-endef
+$(error No libOpenVG implementation selected. Configuration error.)
+endif
 endif
 
 $(eval $(generic-package))
diff --git a/package/powervr/powervr.mk b/package/powervr/powervr.mk
index 1f43505..b36eb16 100644
--- a/package/powervr/powervr.mk
+++ b/package/powervr/powervr.mk
@@ -7,11 +7,10 @@
 POWERVR_SOURCE =
 POWERVR_DEPENDENCIES = $(call qstrip,$(BR2_PACKAGE_PROVIDES_POWERVR))
 
+ifeq ($(BR2_PACKAGE_HAS_POWERVR),y)
 ifeq ($(POWERVR_DEPENDENCIES),)
-define POWERVR_CONFIGURE_CMDS
-	echo "No PowerVR implementation selected. Configuration error."
-	exit 1
-endef
+$(error No PowerVR implementation selected. Configuration error.)
+endif
 endif
 
 $(eval $(generic-package))
-- 
1.7.9.5

[Buildroot] [PATCH 2/2] manual: add virtual package tutorial.

[Eric Le Bihan]

The manual now features a new section with instructions about how to add a
virtual package.

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

diff --git a/docs/manual/adding-packages-virtual.txt b/docs/manual/adding-packages-virtual.txt
new file mode 100644
index 0000000..6cccc4e
--- /dev/null
+++ b/docs/manual/adding-packages-virtual.txt
@@ -0,0 +1,102 @@
+// -*- mode:doc; -*-
+// vim: set syntax=asciidoc:
+
+Infrastructure for virtual packages
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+[[virtual-package-tutorial]]
+
++virtual-package+ tutorial
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In Buildroot, a virtual package is a package whose functionalities are
+provided by one or more packages, referred to as 'providers'. The virtual
+package infrastructure is an extensible mechanism allowing the user to choose
+the provider used in the rootfs.
+
+For example, 'OpenGL ES' is an API for 2D and 3D graphics on embedded systems.
+The implementation of this API is different for the 'Allwinner Tech Sunxi' and
+the 'Texas Instruments OMAP35xx' plaftorms. So +libgles+ will be a virtual
+package and +sunxi-mali+ and +ti-gfx+ will be the providers.
+
+In the following example, we will explain how to add a new virtual package
+('something-virtual') and a provider for it ('some-provider').
+
+First, let's create the virtual package.
+
+.Virtual package +Config.in+ file
+=================================
+The +Config.in+ file of virtual package 'something-virtual' should contain:
+
+---------------------------
+01: config BR2_PACKAGE_HAS_SOMETHING_VIRTUAL
+02:	bool
+03:
+04: config BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL
+05:	depends on BR2_PACKAGE_HAS_SOMETHING_VIRTUAL
+06:	string
+---------------------------
+=================================
+
+In this file, we declare two options, +BR2_PACKAGE_HAS_SOMETHING_VIRTUAL+ and
++BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL+, whose values will be used by the
+providers.
+
+.Virtual package +*.mk+ file
+============================
+The Makefile +package/something-virtual/something-virtual.mk+ should contain:
+
+---------------------------
+01: ################################################################################
+02: #
+03: # something-virtual
+04: #
+05: ################################################################################
+06:
+07: SOMETHING_VIRTUAL_SOURCE =
+08: SOMETHING_VIRTUAL_DEPENDENCIES = $(call qstrip,$(BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL))
+09:
+10: ifeq ($(BR2_PACKAGE_HAS_SOMETHING_VIRTUAL),y)
+11: ifeq ($(SOMETHING_VIRTUAL_DEPENDENCIES),)
+12: $(error No something-virtual implementation selected. Configuration error.)
+13: endif
+14: endif
+15:
+16: $(eval $(generic-package))
+---------------------------
+============================
+
+The Makefile is quite small as it will only check if a provider for the
+virtual package has been selected.
+
+When adding a package as a provider, only the +Config.in+ file requires some
+modifications. The +*.mk+ file should follow the Buildroot infrastructure with
+no change at all.
+
+.Provider +Config.in+ file
+==========================
+The +Config.in+ file of the package 'some-provider', which provides the
+functionalities of 'something-virtual', should contain:
+
+---------------------------
+01: config BR2_PACKAGE_SOME_PROVIDER
+02:	bool "some-provider"
+03:	select BR2_PACKAGE_HAS_SOMETHING_VIRTUAL
+04:	help
+05:	  This is a comment that explains what some-provider is.
+06:
+07:	  http://foosoftware.org/some-provider/
+08:
+09: if BR2_PACKAGE_SOME_PROVIDER
+10: config BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL
+11:	default "some-provider"
+12: endif
+---------------------------
+==========================
+
+On line 3, we select +BR2_PACKAGE_HAS_SOMETHING_VIRTUAL+, and on line 11, we
+set the value of +BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL+ to the name of the
+provider, but only if it is selected.
+
+Of course, do not forget to add the proper build and runtime dependencies for
+this package!
diff --git a/docs/manual/adding-packages.txt b/docs/manual/adding-packages.txt
index 745e33a..dbba930 100644
--- a/docs/manual/adding-packages.txt
+++ b/docs/manual/adding-packages.txt
@@ -24,6 +24,8 @@ include::adding-packages-luarocks.txt[]
 
 include::adding-packages-perl.txt[]
 
+include::adding-packages-virtual.txt[]
+
 include::adding-packages-hooks.txt[]
 
 include::adding-packages-gettext.txt[]
-- 
1.7.9.5

[Buildroot] [PATCH 1/2] infra: improve dependency check in virtual packages.

[Yann E. MORIN]

Eric, All,

On 2014-02-24 10:50 +0100, Eric Le Bihan spake thusly:
> The current version of dependency check for virtual package <foo>
> defines FOO_CONFIGURE_CMDS to print an error message if the
> dependencies are not met.
> 
> This patch updates all the virtual packages to use the GNU Make control
> function $(error text...) instead.
> 
> This makes the error happen at the beginning of the build, with a clearer
> message.
> 
> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>

Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Somewhat-unrelated to this change, see a comment below...

> ---
>  package/luainterpreter/luainterpreter.mk |    6 ++++++
>  package/opengl/libegl/libegl.mk          |    7 +++----
>  package/opengl/libgles/libgles.mk        |    7 +++----
>  package/opengl/libopenmax/libopenmax.mk  |    7 +++----
>  package/opengl/libopenvg/libopenvg.mk    |    7 +++----
>  package/powervr/powervr.mk               |    7 +++----
>  6 files changed, 21 insertions(+), 20 deletions(-)
> 
> diff --git a/package/luainterpreter/luainterpreter.mk b/package/luainterpreter/luainterpreter.mk
> index c37d621..5443477 100644
> --- a/package/luainterpreter/luainterpreter.mk
> +++ b/package/luainterpreter/luainterpreter.mk
> @@ -9,4 +9,10 @@ LUAINTERPRETER_DEPENDENCIES = $(call qstrip,$(BR2_PACKAGE_PROVIDES_LUA_INTERPRET
>  
>  LUAINTERPRETER_ABIVER = $(call qstrip,$(BR2_PACKAGE_LUAINTERPRETER_ABI_VERSION))
>  
> +ifeq ($(BR2_PACKAGE_HAS_LUA_INTERPRETER),y)
> +ifeq ($(LUAINTERPRETER_DEPENDENCIES),)
> +$(error No lua interpreter implementation selected. Configuration error.)
> +endif
> +endif
> +
>  $(eval $(generic-package))
> diff --git a/package/opengl/libegl/libegl.mk b/package/opengl/libegl/libegl.mk
> index b2b74f1..3311e50 100644
> --- a/package/opengl/libegl/libegl.mk
> +++ b/package/opengl/libegl/libegl.mk
> @@ -7,11 +7,10 @@
>  LIBEGL_SOURCE =
>  LIBEGL_DEPENDENCIES = $(call qstrip,$(BR2_PACKAGE_PROVIDES_OPENGL_EGL))
>  
> +ifeq ($(BR2_PACKAGE_HAS_OPENGL_EGL),y)
>  ifeq ($(LIBEGL_DEPENDENCIES),)
> -define LIBEGL_CONFIGURE_CMDS
> -	echo "No libEGL implementation selected. Configuration error."
> -	exit 1
> -endef
> +$(error No libEGL implementation selected. Configuration error.)
> +endif
>  endif
>  
>  $(eval $(generic-package))

I don't know about you folks, but I'm beginning to see a pattern here...

If all of our BR2_PACKAGE_HAS_FOOBAR options would match the corresponding
FOOBAR_DEPENDENCIES, then we could use something like (absolutely untested,
only pure random thoughts):

    $(eval $(call virtual-package,FooBar))

whith 'virtual-package' something like:

    define virtual-package
    ifeq ($(BR2_PACKAGE_HAS_$(call upper,$(1))),y)
    ifeq ($($(call upper,$(1))_DEPENDENCIES),)
    $(error No $(1) implementation selected. Configuration error.)
    endif
    endif
    endef

But then we would need:
    s/BR2_PACKAGE_HAS_OPENGL_EGL/BR2_PACKAGE_HAS_LIBEGL/
    s/BR2_PACKAGE_HAS_OPENGL_GLES/BR2_PACKAGE_HAS_LIBGLES/
    s/BR2_PACKAGE_HAS_OPENMAX/BR2_PACKAGE_HAS_LIBOPENMAX/
    s/BR2_PACKAGE_HAS_OPENVG/BR2_PACKAGE_HAS_LIBOPENVG/

Lua interpreter and PowerVR already match this.

We could even go further, so as to only require a call to 'virtual-package'
and not to 'generic-package', with some carefully-crafted Makefile
constructs (but we would loose the capitalisation of eg. lbEGL, since the
package is named 'libegl', all in lower-case). 'virtual-package' could
even override FOOBAR_SOURCE="" before calling generic-package behind the
hood. This would make writing virtual packages even easier.

Thought?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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] infra: improve dependency check in virtual packages.

[Mike Zick]

On Mon, 24 Feb 2014 19:29:51 +0100
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> Eric, All,
> 
> On 2014-02-24 10:50 +0100, Eric Le Bihan spake thusly:
> > The current version of dependency check for virtual package <foo>
> > defines FOO_CONFIGURE_CMDS to print an error message if the
> > dependencies are not met.
> > 
> > This patch updates all the virtual packages to use the GNU Make
> > control function $(error text...) instead.
> > 
> > This makes the error happen at the beginning of the build, with a
> > clearer message.
> > 
> > Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> 
> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> 
> Somewhat-unrelated to this change, see a comment below...
> 
> > ---
> >  package/luainterpreter/luainterpreter.mk |    6 ++++++
> >  package/opengl/libegl/libegl.mk          |    7 +++----
> >  package/opengl/libgles/libgles.mk        |    7 +++----
> >  package/opengl/libopenmax/libopenmax.mk  |    7 +++----
> >  package/opengl/libopenvg/libopenvg.mk    |    7 +++----
> >  package/powervr/powervr.mk               |    7 +++----
> >  6 files changed, 21 insertions(+), 20 deletions(-)
> > 
> > diff --git a/package/luainterpreter/luainterpreter.mk
> > b/package/luainterpreter/luainterpreter.mk index c37d621..5443477
> > 100644 --- a/package/luainterpreter/luainterpreter.mk
> > +++ b/package/luainterpreter/luainterpreter.mk
> > @@ -9,4 +9,10 @@ LUAINTERPRETER_DEPENDENCIES = $(call
> > qstrip,$(BR2_PACKAGE_PROVIDES_LUA_INTERPRET 
> >  LUAINTERPRETER_ABIVER = $(call
> > qstrip,$(BR2_PACKAGE_LUAINTERPRETER_ABI_VERSION)) 
> > +ifeq ($(BR2_PACKAGE_HAS_LUA_INTERPRETER),y)
> > +ifeq ($(LUAINTERPRETER_DEPENDENCIES),)
> > +$(error No lua interpreter implementation selected. Configuration
> > error.) +endif
> > +endif
> > +
> >  $(eval $(generic-package))
> > diff --git a/package/opengl/libegl/libegl.mk
> > b/package/opengl/libegl/libegl.mk index b2b74f1..3311e50 100644
> > --- a/package/opengl/libegl/libegl.mk
> > +++ b/package/opengl/libegl/libegl.mk
> > @@ -7,11 +7,10 @@
> >  LIBEGL_SOURCE =
> >  LIBEGL_DEPENDENCIES = $(call
> > qstrip,$(BR2_PACKAGE_PROVIDES_OPENGL_EGL)) 
> > +ifeq ($(BR2_PACKAGE_HAS_OPENGL_EGL),y)
> >  ifeq ($(LIBEGL_DEPENDENCIES),)
> > -define LIBEGL_CONFIGURE_CMDS
> > -	echo "No libEGL implementation selected. Configuration
> > error."
> > -	exit 1
> > -endef
> > +$(error No libEGL implementation selected. Configuration error.)
> > +endif
> >  endif
> >  
> >  $(eval $(generic-package))
> 
> I don't know about you folks, but I'm beginning to see a pattern
> here...
> 
> If all of our BR2_PACKAGE_HAS_FOOBAR options would match the
> corresponding FOOBAR_DEPENDENCIES, then we could use something like
> (absolutely untested, only pure random thoughts):
> 
>     $(eval $(call virtual-package,FooBar))
> 
> whith 'virtual-package' something like:
> 
>     define virtual-package
>     ifeq ($(BR2_PACKAGE_HAS_$(call upper,$(1))),y)
>     ifeq ($($(call upper,$(1))_DEPENDENCIES),)
>     $(error No $(1) implementation selected. Configuration error.)
>     endif
>     endif
>     endef
> 
> But then we would need:
>     s/BR2_PACKAGE_HAS_OPENGL_EGL/BR2_PACKAGE_HAS_LIBEGL/
>     s/BR2_PACKAGE_HAS_OPENGL_GLES/BR2_PACKAGE_HAS_LIBGLES/
>     s/BR2_PACKAGE_HAS_OPENMAX/BR2_PACKAGE_HAS_LIBOPENMAX/
>     s/BR2_PACKAGE_HAS_OPENVG/BR2_PACKAGE_HAS_LIBOPENVG/
> 
> Lua interpreter and PowerVR already match this.
> 
> We could even go further, so as to only require a call to
> 'virtual-package' and not to 'generic-package', with some
> carefully-crafted Makefile constructs (but we would loose the
> capitalisation of eg. lbEGL, since the package is named 'libegl', all
> in lower-case). 'virtual-package' could even override
> FOOBAR_SOURCE="" before calling generic-package behind the hood. This
> would make writing virtual packages even easier.
> 
> Thought?
> 

Sounds good to me.
(The first suggestion, without the lost capitalization.)

Mike

> Regards,
> Yann E. MORIN.
> 

[Buildroot] [PATCH 2/2] manual: add virtual package tutorial.

[Yann E. MORIN]

Eric, All,

I think you should base this on master, since we think it would be very
interesting to have it in this release.

On 2014-02-24 10:50 +0100, Eric Le Bihan spake thusly:
> The manual now features a new section with instructions about how to add a
> virtual package.
> 
> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> ---
>  docs/manual/adding-packages-virtual.txt |  102 +++++++++++++++++++++++++++++++
>  docs/manual/adding-packages.txt         |    2 +
>  2 files changed, 104 insertions(+)
>  create mode 100644 docs/manual/adding-packages-virtual.txt
> 
> diff --git a/docs/manual/adding-packages-virtual.txt b/docs/manual/adding-packages-virtual.txt
> new file mode 100644
> index 0000000..6cccc4e
> --- /dev/null
> +++ b/docs/manual/adding-packages-virtual.txt
> @@ -0,0 +1,102 @@
> +// -*- mode:doc; -*-
> +// vim: set syntax=asciidoc:
> +
> +Infrastructure for virtual packages
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +[[virtual-package-tutorial]]
> +
> ++virtual-package+ tutorial
> +^^^^^^^^^^^^^^^^^^^^^^^^^^

'virtual-package' is not an infrastructure [ie. you can't use:
$(eval $(virtual-package)) ], so I would suggest to just use:

    Virtual package tutorial
    ^^^^^^^^^^^^^^^^^^^^^^^^

[--SNIP--]
> +First, let's create the virtual package.
> +
> +.Virtual package +Config.in+ file
> +=================================

The formatting of the title is weird. Here's what I've changed:

    Virtual package +Config.in+ file
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


(notice: no leading dot, and an empty line after the ^^^ line)

> +The +Config.in+ file of virtual package 'something-virtual' should contain:
> +
> +---------------------------
> +01: config BR2_PACKAGE_HAS_SOMETHING_VIRTUAL
> +02:	bool
> +03:
> +04: config BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL
> +05:	depends on BR2_PACKAGE_HAS_SOMETHING_VIRTUAL
> +06:	string
> +---------------------------
> +=================================

Remove this === line.

> +In this file, we declare two options, +BR2_PACKAGE_HAS_SOMETHING_VIRTUAL+ and
> ++BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL+, whose values will be used by the
> +providers.
> +
> +.Virtual package +*.mk+ file
> +============================

Ditto title.

> +The Makefile +package/something-virtual/something-virtual.mk+ should contain:
> +
> +---------------------------
> +01: ################################################################################
> +02: #
> +03: # something-virtual
> +04: #
> +05: ################################################################################
> +06:
> +07: SOMETHING_VIRTUAL_SOURCE =
> +08: SOMETHING_VIRTUAL_DEPENDENCIES = $(call qstrip,$(BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL))
> +09:
> +10: ifeq ($(BR2_PACKAGE_HAS_SOMETHING_VIRTUAL),y)
> +11: ifeq ($(SOMETHING_VIRTUAL_DEPENDENCIES),)
> +12: $(error No something-virtual implementation selected. Configuration error.)
> +13: endif
> +14: endif
> +15:
> +16: $(eval $(generic-package))
> +---------------------------
> +============================

Ditto ===.

> +The Makefile is quite small as it will only check if a provider for the
> +virtual package has been selected.
> +
> +When adding a package as a provider, only the +Config.in+ file requires some
> +modifications. The +*.mk+ file should follow the Buildroot infrastructure with
> +no change at all.
> +
> +.Provider +Config.in+ file
> +==========================

Ditto title.

> +The +Config.in+ file of the package 'some-provider', which provides the
> +functionalities of 'something-virtual', should contain:
> +
> +---------------------------
> +01: config BR2_PACKAGE_SOME_PROVIDER
> +02:	bool "some-provider"
> +03:	select BR2_PACKAGE_HAS_SOMETHING_VIRTUAL
> +04:	help
> +05:	  This is a comment that explains what some-provider is.
> +06:
> +07:	  http://foosoftware.org/some-provider/
> +08:
> +09: if BR2_PACKAGE_SOME_PROVIDER
> +10: config BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL
> +11:	default "some-provider"
> +12: endif
> +---------------------------
> +==========================

Ditto ===.

With those changes, the manual looks better, IMHO.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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] infra: improve dependency check in virtual packages.

[Thomas De Schampheleire]

"Yann E. MORIN" <yann.morin.1998@free.fr> schreef:
...
>
>I don't know about you folks, but I'm beginning to see a pattern here...
>
>If all of our BR2_PACKAGE_HAS_FOOBAR options would match the corresponding
>FOOBAR_DEPENDENCIES, then we could use something like (absolutely untested,
>only pure random thoughts):
>
>    $(eval $(call virtual-package,FooBar))
>
>whith 'virtual-package' something like:
>
>    define virtual-package
>    ifeq ($(BR2_PACKAGE_HAS_$(call upper,$(1))),y)
>    ifeq ($($(call upper,$(1))_DEPENDENCIES),)
>    $(error No $(1) implementation selected. Configuration error.)
>    endif
>    endif
>    endef
>
>But then we would need:
>    s/BR2_PACKAGE_HAS_OPENGL_EGL/BR2_PACKAGE_HAS_LIBEGL/
>    s/BR2_PACKAGE_HAS_OPENGL_GLES/BR2_PACKAGE_HAS_LIBGLES/
>    s/BR2_PACKAGE_HAS_OPENMAX/BR2_PACKAGE_HAS_LIBOPENMAX/
>    s/BR2_PACKAGE_HAS_OPENVG/BR2_PACKAGE_HAS_LIBOPENVG/
>
>Lua interpreter and PowerVR already match this.

In the past I complained about the version of virtual packages (like toolchain) being 'undefined'. The idea came up to set it as 'virtual' instead.
I believe at that time, Thomas also said that renaming the libgl symbols should be fine...

Best regards,
Thomas

[Buildroot] [PATCH 1/2] infra: improve dependency check in virtual packages.

[Eric Le Bihan]

Hi!

On Mon, Feb 24, 2014 at 07:29:51PM +0100, Yann E. MORIN wrote:
[...]
> I don't know about you folks, but I'm beginning to see a pattern here...
>
> If all of our BR2_PACKAGE_HAS_FOOBAR options would match the corresponding
> FOOBAR_DEPENDENCIES, then we could use something like (absolutely untested,
> only pure random thoughts):
>
>     $(eval $(call virtual-package,FooBar))
>
> whith 'virtual-package' something like:
>
>     define virtual-package
>     ifeq ($(BR2_PACKAGE_HAS_$(call upper,$(1))),y)
>     ifeq ($($(call upper,$(1))_DEPENDENCIES),)
>     $(error No $(1) implementation selected. Configuration error.)
>     endif
>     endif
>     endef
>
> But then we would need:
>     s/BR2_PACKAGE_HAS_OPENGL_EGL/BR2_PACKAGE_HAS_LIBEGL/
>     s/BR2_PACKAGE_HAS_OPENGL_GLES/BR2_PACKAGE_HAS_LIBGLES/
>     s/BR2_PACKAGE_HAS_OPENMAX/BR2_PACKAGE_HAS_LIBOPENMAX/
>     s/BR2_PACKAGE_HAS_OPENVG/BR2_PACKAGE_HAS_LIBOPENVG/
IMHO, renaming BR2_PACKAGE_HAS_OPENGL_GLES to BR2_PACKAGE_HAS_LIBGLES and
friends is OK, as it matches the mesa3d naming and sounds less redundant.
> Lua interpreter and PowerVR already match this.
>
> We could even go further, so as to only require a call to 'virtual-package'
> and not to 'generic-package', with some carefully-crafted Makefile
> constructs (but we would loose the capitalisation of eg. lbEGL, since the
> package is named 'libegl', all in lower-case). 'virtual-package' could
> even override FOOBAR_SOURCE="" before calling generic-package behind the
> hood. This would make writing virtual packages even easier.
>
> Thought?
I like the idea. The virtual packages would become one-liners :-)
I'll test it.

Best regards,
ELB

[Buildroot] [PATCH 2/2] manual: add virtual package tutorial.

[Eric Le Bihan]

On Mon, Feb 24, 2014 at 08:01:04PM +0100, Yann E. MORIN wrote:
>
> 'virtual-package' is not an infrastructure [ie. you can't use:
> $(eval $(virtual-package)) ], so I would suggest to just use:
>
>     Virtual package tutorial
>     ^^^^^^^^^^^^^^^^^^^^^^^^
>
Understood.

> > +First, let's create the virtual package.
> > +
> > +.Virtual package +Config.in+ file
> > +=================================
>
> The formatting of the title is weird. Here's what I've changed:
>
>     Virtual package +Config.in+ file
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
> (notice: no leading dot, and an empty line after the ^^^ line)
This was not a title, but an example, as I used +adding-packages-generic.txt+
for inspiration. I thought it was useful to have the code snippets listed in
the example section, so the user could quickly jump to them. But it is true
that:

1. not all the code snippets are listed as examples.
2. the Ascidoc example syntax, mixed with a code snippet, hurts the eyes
   (either in text or in the generated HTML).

I'll change to plain and simple titles.

Best regards,
ELB

[Buildroot] [PATCH 1/2] infra: improve dependency check in virtual packages.

[Arnout Vandecappelle]

On 25/02/14 13:04, Eric Le Bihan wrote:
> Hi!
> 
> On Mon, Feb 24, 2014 at 07:29:51PM +0100, Yann E. MORIN wrote:
> [...]
>> I don't know about you folks, but I'm beginning to see a pattern here...
>>
>> If all of our BR2_PACKAGE_HAS_FOOBAR options would match the corresponding
>> FOOBAR_DEPENDENCIES, then we could use something like (absolutely untested,
>> only pure random thoughts):
>>
>>     $(eval $(call virtual-package,FooBar))
>>
>> whith 'virtual-package' something like:
>>
>>     define virtual-package
>>     ifeq ($(BR2_PACKAGE_HAS_$(call upper,$(1))),y)
>>     ifeq ($($(call upper,$(1))_DEPENDENCIES),)
>>     $(error No $(1) implementation selected. Configuration error.)
>>     endif
>>     endif
>>     endef
>>
>> But then we would need:
>>     s/BR2_PACKAGE_HAS_OPENGL_EGL/BR2_PACKAGE_HAS_LIBEGL/
>>     s/BR2_PACKAGE_HAS_OPENGL_GLES/BR2_PACKAGE_HAS_LIBGLES/
>>     s/BR2_PACKAGE_HAS_OPENMAX/BR2_PACKAGE_HAS_LIBOPENMAX/
>>     s/BR2_PACKAGE_HAS_OPENVG/BR2_PACKAGE_HAS_LIBOPENVG/
> IMHO, renaming BR2_PACKAGE_HAS_OPENGL_GLES to BR2_PACKAGE_HAS_LIBGLES and
> friends is OK, as it matches the mesa3d naming and sounds less redundant.
>> Lua interpreter and PowerVR already match this.
>>
>> We could even go further, so as to only require a call to 'virtual-package'
>> and not to 'generic-package', with some carefully-crafted Makefile
>> constructs (but we would loose the capitalisation of eg. lbEGL, since the
>> package is named 'libegl', all in lower-case). 'virtual-package' could
>> even override FOOBAR_SOURCE="" before calling generic-package behind the
>> hood. This would make writing virtual packages even easier.

 Indeed, I alluded to this in my comments on one of the earlier versions
of Eric's patches.

 In fact, you don't need to do a $(generic-package) at all. Nothing of
the generic package infrastructure is needed for virtual packages: no
source fetching, no building and installing, no legal info, no nothing.
Therefore also the stamp files are redundant. Therefore also the build
directory is redundant. Therefore also the version is redundant.

 The only thing we need is:

$(pkg): $($(PKG)_DEPENDENCIES)

 We probably need a few more in order to propagate the other things that
need dependency chains, perhaps -source and -legal-info (though it looks
like that is still done through the TARGETS_SOURCE variable - I thought
we removed that at some point?).


>>
>> Thought?
> I like the idea. The virtual packages would become one-liners :-)
> I'll test it.

 Make sure you do this on top of -next, because it may be affected by
Fabio's parallel build changes.

 Regards,
 Arnout

> 
> Best regards,
> ELB
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 
> 


-- 
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 2/2] manual: add virtual package tutorial.

[Arnout Vandecappelle]

On 24/02/14 20:01, Yann E. MORIN wrote:
> Eric, All,
> 
> I think you should base this on master, since we think it would be very
> interesting to have it in this release.

 I don't think it's that important. I don't think people will be adding
virtual packages for their custom stuff, so this documentation is
targeted towards people that will upstream packages. And for these, we
can assume that they read the documentation of master and not that of
whatever release they happen to be working with.

 And of course, if the $(virtual-package) infrastructure gets added, then
this piece of documentation has to be entirely rewritten.

> 
> On 2014-02-24 10:50 +0100, Eric Le Bihan spake thusly:
>> The manual now features a new section with instructions about how to add a
>> virtual package.
>>
>> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
>> ---
>>  docs/manual/adding-packages-virtual.txt |  102 +++++++++++++++++++++++++++++++
>>  docs/manual/adding-packages.txt         |    2 +
>>  2 files changed, 104 insertions(+)
>>  create mode 100644 docs/manual/adding-packages-virtual.txt
>>
>> diff --git a/docs/manual/adding-packages-virtual.txt b/docs/manual/adding-packages-virtual.txt
>> new file mode 100644
>> index 0000000..6cccc4e
>> --- /dev/null
>> +++ b/docs/manual/adding-packages-virtual.txt
>> @@ -0,0 +1,102 @@
>> +// -*- mode:doc; -*-
>> +// vim: set syntax=asciidoc:
>> +
>> +Infrastructure for virtual packages
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +[[virtual-package-tutorial]]
>> +
>> ++virtual-package+ tutorial
>> +^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> 'virtual-package' is not an infrastructure [ie. you can't use:
> $(eval $(virtual-package)) ], 

 Well, soon you will be able to! :-)


 Regards,
 Arnout

> so I would suggest to just use:
> 
>     Virtual package tutorial
>     ^^^^^^^^^^^^^^^^^^^^^^^^
> 
> [--SNIP--]
>> +First, let's create the virtual package.
>> +
>> +.Virtual package +Config.in+ file
>> +=================================
> 
> The formatting of the title is weird. Here's what I've changed:
> 
>     Virtual package +Config.in+ file
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> 
> (notice: no leading dot, and an empty line after the ^^^ line)
> 
>> +The +Config.in+ file of virtual package 'something-virtual' should contain:
>> +
>> +---------------------------
>> +01: config BR2_PACKAGE_HAS_SOMETHING_VIRTUAL
>> +02:	bool
>> +03:
>> +04: config BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL
>> +05:	depends on BR2_PACKAGE_HAS_SOMETHING_VIRTUAL
>> +06:	string
>> +---------------------------
>> +=================================
> 
> Remove this === line.
> 
>> +In this file, we declare two options, +BR2_PACKAGE_HAS_SOMETHING_VIRTUAL+ and
>> ++BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL+, whose values will be used by the
>> +providers.
>> +
>> +.Virtual package +*.mk+ file
>> +============================
> 
> Ditto title.
> 
>> +The Makefile +package/something-virtual/something-virtual.mk+ should contain:
>> +
>> +---------------------------
>> +01: ################################################################################
>> +02: #
>> +03: # something-virtual
>> +04: #
>> +05: ################################################################################
>> +06:
>> +07: SOMETHING_VIRTUAL_SOURCE =
>> +08: SOMETHING_VIRTUAL_DEPENDENCIES = $(call qstrip,$(BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL))
>> +09:
>> +10: ifeq ($(BR2_PACKAGE_HAS_SOMETHING_VIRTUAL),y)
>> +11: ifeq ($(SOMETHING_VIRTUAL_DEPENDENCIES),)
>> +12: $(error No something-virtual implementation selected. Configuration error.)
>> +13: endif
>> +14: endif
>> +15:
>> +16: $(eval $(generic-package))
>> +---------------------------
>> +============================
> 
> Ditto ===.
> 
>> +The Makefile is quite small as it will only check if a provider for the
>> +virtual package has been selected.
>> +
>> +When adding a package as a provider, only the +Config.in+ file requires some
>> +modifications. The +*.mk+ file should follow the Buildroot infrastructure with
>> +no change at all.
>> +
>> +.Provider +Config.in+ file
>> +==========================
> 
> Ditto title.
> 
>> +The +Config.in+ file of the package 'some-provider', which provides the
>> +functionalities of 'something-virtual', should contain:
>> +
>> +---------------------------
>> +01: config BR2_PACKAGE_SOME_PROVIDER
>> +02:	bool "some-provider"
>> +03:	select BR2_PACKAGE_HAS_SOMETHING_VIRTUAL
>> +04:	help
>> +05:	  This is a comment that explains what some-provider is.
>> +06:
>> +07:	  http://foosoftware.org/some-provider/
>> +08:
>> +09: if BR2_PACKAGE_SOME_PROVIDER
>> +10: config BR2_PACKAGE_PROVIDES_SOMETHING_VIRTUAL
>> +11:	default "some-provider"
>> +12: endif
>> +---------------------------
>> +==========================
> 
> Ditto ===.
> 
> With those changes, the manual looks better, IMHO.
> 
> Regards,
> Yann E. MORIN.
> 


-- 
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F