The check-package script when ran gives warnings on ordering issues
on all of these Config files. This patch cleans up all warnings
related to the ordering in the Config files for packages starting with
the letter o in the package directory.
The appropriate ordering is: type, default, depends on, select, help
See http://nightly.buildroot.org/#_config_files for more information.
Signed-off-by: Adam Duskett <Adamduskett@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The gpu-viv-bin-mx6q package selects BR2_PACKAGE_HAS_OPENGL_EGL and
BR2_PACKAGE_HAS_OPENGL_ES, so when it is enabled, Buildroot believes
that OpenGL and EGL support is available.
However, both libgles.mk and libegl.mk do not add the dependency on
gpu-viv-bin-mx6q, so when pulling the libgles or libegl dependencies,
the build fails due to the absence of an OpenGL implementation. This
commit fixes that.
Fixes the build failure at
http://autobuild.buildroot.org/results/dbd/dbd938914883a9e205f967f7b4b4a8a7dc7be117/build-end.log.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
I believe the original intent was to make it that the configure step
for the opengl virtual packages fails if there is not at least one
dependency. This patch fixes the logic so that it actually fails if
dependency list is empty
Signed-off-by: Will Wagner <will_wagner@carallon.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Those acceleration libraries typically have multiple implementations:
some are free (Mesa), some are proprietary (generally SoC specific).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
