Ability to specify regular packages behaviour from external.mk

I have been testing BR2_EXTERNAL to generate a firmware for a target that provides proprietary egl and gles implementations.

I have created a custom userland package for my target that "provides" egl and gles, but I still need to specify a dependency towards it in libegl and libgles.

Before BR2_EXTERNAL, I used to patch buildroot's package/opengl/libgles.mk and package/opengl/libegl.mk directly:

ifeq ($(BR2_PACKAGE_XX_USERLAND),y)
LIBGLES_DEPENDENCIES += xx-userland
endif

Now, I would like to add these lines to my external.mk, but I fail on a LIBXX_CONFIGURE_CMDS that exits on error if LIBGLES_DEPENDENCIES are empty.

The thing is that since external.mk is included after all other makefiles, my modifications to LIBXX_DEPENDENCIES are applied only after the creation of the LIBXX_CONFIGURE_CMDS, thus causing the exit on error.

I managed to overcome this issue by moving the inclusion of external.mk before all other makefiles, but I have no idea if this is the right way to go: what do you think ?

From: "Yann E. MORIN" <[email protected]>

Because some GLES providers may be in BR2_EXTERNAL, $(LIBGLES_DEPENDENCIES) might be empty hwen we test it.

So, we can't rely on it to define LIBGLES_CONFIGURE_CMDS, and we must postpone the check until later, ie. at runtime.

Signed-off-by "Yann E. MORIN" <[email protected]>

---
  package/opengl/libgles/libgles.mk | 13 +++++++++----
  1 file changed, 9 insertions(+), 4 deletions(-)

package/opengl/libgles/libgles.mk +0 -0

index ec157ac..c2e1acf 100644
@@ -22,11 +22,16 @@ ifeq ($(BR2_PACKAGE_GPU_VIV_BIN_MX6Q),y)
  LIBGLES_DEPENDENCIES += gpu-viv-bin-mx6q
  endif
 

package/opengl/libgles/libgles.mk +3 -1

+		echo "No libGLES implementation selected. Configuration error."; \
+		exit 1; \
+	fi
  endef
-endif
 
  $(eval $(generic-package))

Quoted 21 lines · Yann E. MORIN

From: "Yann E. MORIN" <[email protected]>

Because some GLES providers may be in BR2_EXTERNAL, $(LIBGLES_DEPENDENCIES) might be empty hwen we test it.

So, we can't rely on it to define LIBGLES_CONFIGURE_CMDS, and we must postpone the check until later, ie. at runtime.

Signed-off-by "Yann E. MORIN" <[email protected]>

---
  package/opengl/libgles/libgles.mk | 13 +++++++++----
  1 file changed, 9 insertions(+), 4 deletions(-)

package/opengl/libgles/libgles.mk +0 -0

index ec157ac..c2e1acf 100644
@@ -22,11 +22,16 @@ ifeq ($(BR2_PACKAGE_GPU_VIV_BIN_MX6Q),y)
  LIBGLES_DEPENDENCIES += gpu-viv-bin-mx6q
  endif
 

package/opengl/libgles/libgles.mk ifeq ($(BR2_PACKAGE_GPU_VIV_BIN_MX6Q),y) · line 31

Quoted 10 lines

package/opengl/libgles/libgles.mk +6 -3

-ifeq ($(LIBGLES_DEPENDENCIES),)
+# Because some GLES providers may be in BR2_EXTERNAL,
+# $(LIBGLES_DEPENDENCIES) might be empty right here.
+# So, we can't rely on it to define LIBGLES_CONFIGURE_CMDS
+# right now, and we must postpone the check until later,
+# ie. at runtime.
  define LIBGLES_CONFIGURE_CMDS
-	echo "No libGLES implementation selected. Configuration error."
-	exit 1
+	if [ -z "$${LIBGLES_DEPENDENCIES}" ]; then \

This should be "$(LIBGLES_DEPENDENCIES)", but otherwise it looks like
it would work.

Arnout, All,

Quoted 22 lines · On Wednesday 11 December 2013 11:46:59 Arnout Vandecappelle wrote:

Quoted 21 lines · Yann E. MORIN

From: "Yann E. MORIN" <[email protected]>

Because some GLES providers may be in BR2_EXTERNAL, $(LIBGLES_DEPENDENCIES) might be empty hwen we test it.

So, we can't rely on it to define LIBGLES_CONFIGURE_CMDS, and we must postpone the check until later, ie. at runtime.

Signed-off-by "Yann E. MORIN" <[email protected]>

---
   package/opengl/libgles/libgles.mk | 13 +++++++++----
   1 file changed, 9 insertions(+), 4 deletions(-)

package/opengl/libgles/libgles.mk +0 -0

index ec157ac..c2e1acf 100644
@@ -22,11 +22,16 @@ ifeq ($(BR2_PACKAGE_GPU_VIV_BIN_MX6Q),y)
   LIBGLES_DEPENDENCIES += gpu-viv-bin-mx6q
   endif
 

Quoted 12 lines

package/opengl/libgles/libgles.mk ifeq ($(BR2_PACKAGE_GPU_VIV_BIN_MX6Q),y) · line 31

Quoted 10 lines

package/opengl/libgles/libgles.mk +6 -3

-ifeq ($(LIBGLES_DEPENDENCIES),)
+# Because some GLES providers may be in BR2_EXTERNAL,
+# $(LIBGLES_DEPENDENCIES) might be empty right here.
+# So, we can't rely on it to define LIBGLES_CONFIGURE_CMDS
+# right now, and we must postpone the check until later,
+# ie. at runtime.
   define LIBGLES_CONFIGURE_CMDS
-	echo "No libGLES implementation selected. Configuration error."
-	exit 1
+	if [ -z "$${LIBGLES_DEPENDENCIES}" ]; then \

This should be "$(LIBGLES_DEPENDENCIES)", but otherwise it looks like
it would work.

I was afraid using a make variable here would be expanded too early again, that's why I postponed its expansion into the shell command itself.

But it does not work either, since the variable is not exported.

I'm waiting for feedback from David to confirm either or both solutions work...

Regards,
Yann E. MORIN.

Guys,

The first solution did not work (as yann pointed out, the variable is not exported), but the second does.
Who's in for a patch (me ?)

David

Sorry, I did another try from a clean environment and the second solution didn't work either: LIBGLES_DEPENDENCIES has the right (modified) value when it the LIBGLES_CONFIGURE_CMDS is evaluated, but not when the dependencies themselves are evaluated (I think it happens in pkg-generic.mk).

So, the build doesn't fail on the LIBGLES_CONFIGURE_CMDS test, but if the xx_userland package has not been installed beforehand, it is not installed automatically when libgles is built.

David

Le 11/12/2013 14:03, David Corvoysier a ?crit :

Quoted 8 lines

Guys,

The first solution did not work (as yann pointed out, the variable is not exported), but the second does.
Who's in for a patch (me ?)

David

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Thomas, do you remember what was the reason to include external.mk
after package/*/*.mk rather than before? If there is no specific reason for it, we could move it.

I also feel that the way the opengl stuff is handled now is a bit
hacky, but I don't have any better ideas.

Quoted 2 lines

Quoted 2 lines

I also feel that the way the opengl stuff is handled now is a bit
hacky, but I don't have any better ideas.

Huh? Can you be more specific in what you find hacky? The way the OpenGL stuff is handled today is kind of becoming the norm to handle virtual packages, so it'd be good to understand what you think is hacky in this implementation.

Quoted 4 lines

Huh? Can you be more specific in what you find hacky? The way the OpenGL stuff is handled today is kind of becoming the norm to handle virtual packages, so it'd be good to understand what you think is hacky in this implementation.

It's hacky because you have double binding between opengl/libgles
and the gles suppliers: opengl/libgles/libgles.mk enumerates all possible suppliers, and the suppliers select BR2_PACKAGE_HAS_OPENGL_ES.

Quoted 9 lines · Arnout Vandecappelle

Quoted 4 lines

Huh? Can you be more specific in what you find hacky? The way the OpenGL stuff is handled today is kind of becoming the norm to handle virtual packages, so it'd be good to understand what you think is hacky in this implementation.

It's hacky because you have double binding between opengl/libgles
and the gles suppliers: opengl/libgles/libgles.mk enumerates all possible suppliers, and the suppliers select BR2_PACKAGE_HAS_OPENGL_ES.

Ok, I understand. Even though I don't think it's really a major issue, I believe there are two possible directions to fix this:

1. Since the .mk part is centralized in opengl/libgles, but the Config.in is not (spread in each OpenGL implementation doing the select BR2_PACKAGE_HAS_OPENGL_ES), we can centralize the Config.in logic by removing the "select BR2_PACKAGE_HAS_OPENGL_ES" in each OpenGL implementation, and define BR2_PACKAGE_HAS_OPENGL_EL as something like:

config BR2_PACKAGE_HAS_OPENGL_ES
bool
default y if BR2_PACKAGE_RPI_FIRMWARE
default y if BR2_PACKAGE_THIS_OTHER_OPENGL_IMPLEMENTATION default y if BR2_PACKAGE_...

2. Or, we can take the opposite route by pushing the currently centralized libgles.mk logic that adds each OpenGL implementation in LIBGLES_DEPENDENCIES down into each OpenGL implementation .mk file. But that requires a late evaluation of $(generic-package), so that all OpenGL implementations can be registered in LIBGLES_DEPENDENCIES before the generic-package macro of libgles.mk is evaluated. This would require something like Yann's patch.

Quoted 7 lines

1. Since the .mk part is centralized in opengl/libgles, but the Config.in is not (spread in each OpenGL implementation doing the select BR2_PACKAGE_HAS_OPENGL_ES), we can centralize the
Config.in logic by removing the "select BR2_PACKAGE_HAS_OPENGL_ES" in each OpenGL implementation, and define BR2_PACKAGE_HAS_OPENGL_EL as something like:

Quoted 5 lines

config BR2_PACKAGE_HAS_OPENGL_ES
bool
default y if BR2_PACKAGE_RPI_FIRMWARE
default y if BR2_PACKAGE_THIS_OTHER_OPENGL_IMPLEMENTATION default y if BR2_PACKAGE_...

With this first proposal, it becomes a bit more complex to implement providers in BR2_EXTERNAL.

Quoted 8 lines

2. Or, we can take the opposite route by pushing the currently centralized libgles.mk logic that adds each OpenGL
implementation in LIBGLES_DEPENDENCIES down into each OpenGL implementation .mk file. But that requires a late evaluation of $(generic-package), so that all OpenGL implementations can be registered in LIBGLES_DEPENDENCIES before the generic-package macro of libgles.mk is evaluated. This would require something like Yann's patch.

Needless to say I would highly prefer this second solution.

Quoted 9 lines

Quoted 8 lines

2. Or, we can take the opposite route by pushing the currently centralized libgles.mk logic that adds each OpenGL
implementation in LIBGLES_DEPENDENCIES down into each OpenGL implementation .mk file. But that requires a late evaluation of $(generic-package), so that all OpenGL implementations can be registered in LIBGLES_DEPENDENCIES before the generic-package macro of libgles.mk is evaluated. This would require something like Yann's patch.

Quoted 1 line

Needless to say I would highly prefer this second solution.

Right. In principle, I have nothing against this solution. It's just that I am not sure to fully grasp the consequences of the change you're proposing. I'm a bit worried about "weird" consequences that we may not be thinking of at this time. But maybe we should simply apply the patch, and see if it causes problems for some specific use cases.

Dear Yann E. MORIN,

Quoted 13 lines · Yann E. MORIN

Quoted 12 lines

1. Since the .mk part is centralized in opengl/libgles, but the Config.in is not (spread in each OpenGL implementation doing the select BR2_PACKAGE_HAS_OPENGL_ES), we can centralize the
Config.in logic by removing the "select BR2_PACKAGE_HAS_OPENGL_ES" in each OpenGL implementation, and define BR2_PACKAGE_HAS_OPENGL_EL as something like:

config BR2_PACKAGE_HAS_OPENGL_ES
bool
default y if BR2_PACKAGE_RPI_FIRMWARE
default y if BR2_PACKAGE_THIS_OTHER_OPENGL_IMPLEMENTATION default y if BR2_PACKAGE_...

Quoted 2 lines

With this first proposal, it becomes a bit more complex to implement providers in BR2_EXTERNAL.

Ah, true.

Quoted 10 lines

Quoted 9 lines

2. Or, we can take the opposite route by pushing the currently centralized libgles.mk logic that adds each OpenGL
implementation in LIBGLES_DEPENDENCIES down into each OpenGL implementation .mk file. But that requires a late evaluation of $(generic-package), so that all OpenGL implementations can be registered in LIBGLES_DEPENDENCIES before the generic-package macro of libgles.mk is evaluated. This would require something like Yann's patch.

Quoted 1 line

Needless to say I would highly prefer this second solution.

Right. In principle, I have nothing against this solution. It's just that I am not sure to fully grasp the consequences of the change you're proposing. I'm a bit worried about "weird" consequences that we may not be thinking of at this time. But maybe we should simply apply the patch, and see if it causes problems for some specific use cases.

Quoted 17 lines

Dear Yann E. MORIN,

Quoted 13 lines · Yann E. MORIN

Quoted 12 lines

1. Since the .mk part is centralized in opengl/libgles, but the Config.in is not (spread in each OpenGL implementation doing the select BR2_PACKAGE_HAS_OPENGL_ES), we can centralize the
Config.in logic by removing the "select BR2_PACKAGE_HAS_OPENGL_ES" in each OpenGL implementation, and define BR2_PACKAGE_HAS_OPENGL_EL as something like:

config BR2_PACKAGE_HAS_OPENGL_ES
bool
default y if BR2_PACKAGE_RPI_FIRMWARE
default y if BR2_PACKAGE_THIS_OTHER_OPENGL_IMPLEMENTATION default y if BR2_PACKAGE_...

Quoted 4 lines

Quoted 2 lines

With this first proposal, it becomes a bit more complex to implement providers in BR2_EXTERNAL.

Ah, true.

Also it feels inconvenient to me that the virtual package should "know"
about all its providers.

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

2. Or, we can take the opposite route by pushing the currently centralized libgles.mk logic that adds each OpenGL
implementation in LIBGLES_DEPENDENCIES down into each OpenGL implementation .mk file. But that requires a late evaluation of $(generic-package), so that all OpenGL implementations can be registered in LIBGLES_DEPENDENCIES before the generic-package macro of libgles.mk is evaluated. This would require something like Yann's patch.

Quoted 7 lines

Quoted 1 line

Needless to say I would highly prefer this second solution.

Right. In principle, I have nothing against this solution. It's just that I am not sure to fully grasp the consequences of the change you're proposing. I'm a bit worried about "weird" consequences that we may not be thinking of at this time. But maybe we should simply apply the patch, and see if it causes problems for some specific use cases.

I'm also a bit afraid of the consequences. It also makes make processing,
which is already difficult to understand, even more obfuscated.

Here's a wild idea...

In rpi-userland/Config.in:

if BR2_PACKAGE_RPI_USERLAND
config BR2_PACKAGE_LIBEGL_PROVIDER
string
default "rpi-userland"
endif

In opengl/libegl/libegl.mk:

LIBEGL_DEPENDENCIES = $(call qstrip,$(BR2PACKAGE_LIBEGL_PROVIDER))

It's still hackish of course, because:

- rpi-userland/Config.in defines a symbol "belonging" to the libegl package;

- only one provider can be defined, Kconfig will scream if it's defined twice;

- it may not work at all :-).

Arnout, All,

On 2013-12-17 23:20 +0100, Arnout Vandecappelle spake thusly:

Quoted 10 lines

Here's a wild idea...

In rpi-userland/Config.in:

if BR2_PACKAGE_RPI_USERLAND
config BR2_PACKAGE_LIBEGL_PROVIDER
string
default "rpi-userland"
endif

Quoted 4 lines

In opengl/libegl/libegl.mk:

LIBEGL_DEPENDENCIES = $(call qstrip,$(BR2PACKAGE_LIBEGL_PROVIDER))

That's about what I am experimenting right now! :-p

But I've done it slightly differently:

package/opengl/libegl/Config.in:
config BR2_LIBEGL_PROVIDER
string

package/rpi-userland/Config.in:
config BR2_LIBEGL_PROVIDER
default "rpi-userland" if BR2_PACKAGE_RPI_USERLAND

And the same .mk fragment you suggested for libegl.

My solution is a little bit more compact, and since it does not use a package-named variable, we can say that packages do not step on one-another's feet. Yet, a bit hackish, I have to concede...

Quoted 3 lines

It's still hackish of course, because:

Quoted 4 lines

- rpi-userland/Config.in defines a symbol "belonging" to the libegl package;

- only one provider can be defined, Kconfig will scream if it's defined twice;

Is it even valid to have two providers of the same functioanlity? What would happen: what libEGL.so would be used? Probably the last one installed, ie. the one from the alphabetically-last provider.

Quoted 2 lines

- it may not work at all :-).

I'll tell you when I'm done with my checks... ;-p

Regards,
Yann E. MORIN.

Quoted 3 lines

Arnout, All,

On 2013-12-17 23:20 +0100, Arnout Vandecappelle spake thusly:

[snip]

Quoted 23 lines

Quoted 10 lines

Here's a wild idea...

In rpi-userland/Config.in:

if BR2_PACKAGE_RPI_USERLAND
config BR2_PACKAGE_LIBEGL_PROVIDER
string
default "rpi-userland"
endif

Quoted 4 lines

In opengl/libegl/libegl.mk:

LIBEGL_DEPENDENCIES = $(call qstrip,$(BR2PACKAGE_LIBEGL_PROVIDER))

That's about what I am experimenting right now! :-p

But I've done it slightly differently:

package/opengl/libegl/Config.in:
config BR2_LIBEGL_PROVIDER
string

Quoted 5 lines

package/rpi-userland/Config.in:
config BR2_LIBEGL_PROVIDER
default "rpi-userland" if BR2_PACKAGE_RPI_USERLAND

And the same .mk fragment you suggested for libegl.

Nice! I'm all for it! I didn't know it was allowed in Kconfig to define the
same symbol twice. But indeed, we already do that in arch/

Quoted 12 lines

My solution is a little bit more compact, and since it does not use a package-named variable, we can say that packages do not step on one-another's feet. Yet, a bit hackish, I have to concede...

Quoted 7 lines

It's still hackish of course, because:

- rpi-userland/Config.in defines a symbol "belonging" to the libegl package;

- only one provider can be defined, Kconfig will scream if it's defined twice;

Quoted 3 lines

Is it even valid to have two providers of the same functioanlity? What would happen: what libEGL.so would be used? Probably the last one installed, ie. the one from the alphabetically-last provider.

Completely true. With your construct, if somehow two providers are
selected, Kconfig will probably just give you the first-sourced provider.