kumquat-buildroot/package/mesa3d-headers/mesa3d-headers.mk

81 lines
2.2 KiB
Makefile
Raw Normal View History

package/mesa3d-headers: new package Some OpenGL/EGL/GLES/VG providers do not provide the corresponding headers, and rely on using "the headers provided by the distribution". In our case, we can not rely on such headers, because we are not a distribution, and we have no way to provide those headers (not even speaking about relying on the headers provided by hte host distribution, because they might well not be installed at all). Also, we can not rely on another package to provide those headers, because we can only have one provider enabled in any configuration. The Khronos group provides such headers, and they are the reference headers, but we can not realy use them: - most of them are not packaged: they are not versioned and not provided in a tarball, but as separately downloadable files; - those headers are anyway incomplete: there are headers not provided by Khronos, like GL.h Instead, we rely on mesa3d to provide those headers: mesa3d has all the headers we need. Modifying the existing mesa3d package would not be easy; we'd have to differentiate whther we need only the headers or the full package. The meas3d Config.in and .mk are already quite non-trivial that adding such a feature would render them even more illegible. So, we introduce mea3d-headers as a new package, that is in fact just mesa3d with a much simplified Config.in and .mk, that other OpenXXX providers may select if they do not provide the OpenXXX headers. Note: we're not installing GLES3 headers, because what Buildroot currently calls libgles is in fact libgles2; we have no way to specify that we have libgles3. So, we just install headers for GLES and GLES2. [Thomas: - Wrap Config.in help text to a reasonable length. - Don't rely on mesa3d to provide mesa3d-headers: they should be mutually exclusive. Instead, error out if both packages are selected. - Take into account the update of mesa3d to 10.4.5. - Don't copy each header file individually, use a cp -dpfr call to copy entires header files directories.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-10 21:01:10 +01:00
################################################################################
#
# mesa3d-headers
#
################################################################################
# mesa3d-headers is inherently incompatible with mesa3d, so error out
# if both are enabled.
ifeq ($(BR2_PACKAGE_MESA3D)$(BR2_PACKAGE_MESA3D_HEADERS),yy)
$(error mesa3d-headers enabled, but mesa3d enabled too)
endif
# Not possible to directly refer to mesa3d variables, because of
# first/second expansion trickery...
MESA3D_HEADERS_VERSION = 18.3.1
MESA3D_HEADERS_SOURCE = mesa-$(MESA3D_HEADERS_VERSION).tar.xz
MESA3D_HEADERS_SITE = https://mesa.freedesktop.org/archive
MESA3D_HEADERS_DL_SUBDIR = mesa3d
package/mesa3d-headers: new package Some OpenGL/EGL/GLES/VG providers do not provide the corresponding headers, and rely on using "the headers provided by the distribution". In our case, we can not rely on such headers, because we are not a distribution, and we have no way to provide those headers (not even speaking about relying on the headers provided by hte host distribution, because they might well not be installed at all). Also, we can not rely on another package to provide those headers, because we can only have one provider enabled in any configuration. The Khronos group provides such headers, and they are the reference headers, but we can not realy use them: - most of them are not packaged: they are not versioned and not provided in a tarball, but as separately downloadable files; - those headers are anyway incomplete: there are headers not provided by Khronos, like GL.h Instead, we rely on mesa3d to provide those headers: mesa3d has all the headers we need. Modifying the existing mesa3d package would not be easy; we'd have to differentiate whther we need only the headers or the full package. The meas3d Config.in and .mk are already quite non-trivial that adding such a feature would render them even more illegible. So, we introduce mea3d-headers as a new package, that is in fact just mesa3d with a much simplified Config.in and .mk, that other OpenXXX providers may select if they do not provide the OpenXXX headers. Note: we're not installing GLES3 headers, because what Buildroot currently calls libgles is in fact libgles2; we have no way to specify that we have libgles3. So, we just install headers for GLES and GLES2. [Thomas: - Wrap Config.in help text to a reasonable length. - Don't rely on mesa3d to provide mesa3d-headers: they should be mutually exclusive. Instead, error out if both packages are selected. - Take into account the update of mesa3d to 10.4.5. - Don't copy each header file individually, use a cp -dpfr call to copy entires header files directories.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-10 21:01:10 +01:00
MESA3D_HEADERS_LICENSE = MIT, SGI, Khronos
MESA3D_HEADERS_LICENSE_FILES = docs/license.html
# Only installs header files
MESA3D_HEADERS_INSTALL_STAGING = YES
MESA3D_HEADERS_INSTALL_TARGET = NO
MESA3D_HEADERS_DIRS = KHR
ifeq ($(BR2_PACKAGE_HAS_LIBGL),y)
package/mesa3d-headers: new package Some OpenGL/EGL/GLES/VG providers do not provide the corresponding headers, and rely on using "the headers provided by the distribution". In our case, we can not rely on such headers, because we are not a distribution, and we have no way to provide those headers (not even speaking about relying on the headers provided by hte host distribution, because they might well not be installed at all). Also, we can not rely on another package to provide those headers, because we can only have one provider enabled in any configuration. The Khronos group provides such headers, and they are the reference headers, but we can not realy use them: - most of them are not packaged: they are not versioned and not provided in a tarball, but as separately downloadable files; - those headers are anyway incomplete: there are headers not provided by Khronos, like GL.h Instead, we rely on mesa3d to provide those headers: mesa3d has all the headers we need. Modifying the existing mesa3d package would not be easy; we'd have to differentiate whther we need only the headers or the full package. The meas3d Config.in and .mk are already quite non-trivial that adding such a feature would render them even more illegible. So, we introduce mea3d-headers as a new package, that is in fact just mesa3d with a much simplified Config.in and .mk, that other OpenXXX providers may select if they do not provide the OpenXXX headers. Note: we're not installing GLES3 headers, because what Buildroot currently calls libgles is in fact libgles2; we have no way to specify that we have libgles3. So, we just install headers for GLES and GLES2. [Thomas: - Wrap Config.in help text to a reasonable length. - Don't rely on mesa3d to provide mesa3d-headers: they should be mutually exclusive. Instead, error out if both packages are selected. - Take into account the update of mesa3d to 10.4.5. - Don't copy each header file individually, use a cp -dpfr call to copy entires header files directories.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-10 21:01:10 +01:00
MESA3D_HEADERS_DIRS += GL
ifeq ($(BR2_PACKAGE_XORG7),y)
# Not using $(SED) because we do not want to work in-place, and $(SED)
# contains -i.
define MESA3D_HEADERS_BUILD_DRI_PC
sed -e 's:@\(exec_\)\?prefix@:/usr:' \
-e 's:@libdir@:$${exec_prefix}/lib:' \
-e 's:@includedir@:$${prefix}/include:' \
-e 's:@DRI_DRIVER_INSTALL_DIR@:$${libdir}/dri:' \
-e 's:@VERSION@:$(MESA3D_HEADERS_VERSION):' \
-e 's:@DRI_PC_REQ_PRIV@::' \
$(@D)/src/mesa/drivers/dri/dri.pc.in \
>$(@D)/src/mesa/drivers/dri/dri.pc
endef
define MESA3D_HEADERS_INSTALL_DRI_PC
$(INSTALL) -D -m 0644 $(@D)/include/GL/internal/dri_interface.h \
$(STAGING_DIR)/usr/include/GL/internal/dri_interface.h
$(INSTALL) -D -m 0644 $(@D)/src/mesa/drivers/dri/dri.pc \
$(STAGING_DIR)/usr/lib/pkgconfig/dri.pc
endef
endif # Xorg
endif # OpenGL
package/mesa3d-headers: new package Some OpenGL/EGL/GLES/VG providers do not provide the corresponding headers, and rely on using "the headers provided by the distribution". In our case, we can not rely on such headers, because we are not a distribution, and we have no way to provide those headers (not even speaking about relying on the headers provided by hte host distribution, because they might well not be installed at all). Also, we can not rely on another package to provide those headers, because we can only have one provider enabled in any configuration. The Khronos group provides such headers, and they are the reference headers, but we can not realy use them: - most of them are not packaged: they are not versioned and not provided in a tarball, but as separately downloadable files; - those headers are anyway incomplete: there are headers not provided by Khronos, like GL.h Instead, we rely on mesa3d to provide those headers: mesa3d has all the headers we need. Modifying the existing mesa3d package would not be easy; we'd have to differentiate whther we need only the headers or the full package. The meas3d Config.in and .mk are already quite non-trivial that adding such a feature would render them even more illegible. So, we introduce mea3d-headers as a new package, that is in fact just mesa3d with a much simplified Config.in and .mk, that other OpenXXX providers may select if they do not provide the OpenXXX headers. Note: we're not installing GLES3 headers, because what Buildroot currently calls libgles is in fact libgles2; we have no way to specify that we have libgles3. So, we just install headers for GLES and GLES2. [Thomas: - Wrap Config.in help text to a reasonable length. - Don't rely on mesa3d to provide mesa3d-headers: they should be mutually exclusive. Instead, error out if both packages are selected. - Take into account the update of mesa3d to 10.4.5. - Don't copy each header file individually, use a cp -dpfr call to copy entires header files directories.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-10 21:01:10 +01:00
ifeq ($(BR2_PACKAGE_HAS_LIBEGL),y)
MESA3D_HEADERS_DIRS += EGL
endif
ifeq ($(BR2_PACKAGE_HAS_LIBGLES),y)
MESA3D_HEADERS_DIRS += GLES GLES2
endif
ifeq ($(BR2_PACKAGE_HAS_LIBOPENCL),y)
MESA3D_HEADERS_DIRS += CL
endif
define MESA3D_HEADERS_BUILD_CMDS
$(MESA3D_HEADERS_BUILD_DRI_PC)
endef
package/mesa3d-headers: new package Some OpenGL/EGL/GLES/VG providers do not provide the corresponding headers, and rely on using "the headers provided by the distribution". In our case, we can not rely on such headers, because we are not a distribution, and we have no way to provide those headers (not even speaking about relying on the headers provided by hte host distribution, because they might well not be installed at all). Also, we can not rely on another package to provide those headers, because we can only have one provider enabled in any configuration. The Khronos group provides such headers, and they are the reference headers, but we can not realy use them: - most of them are not packaged: they are not versioned and not provided in a tarball, but as separately downloadable files; - those headers are anyway incomplete: there are headers not provided by Khronos, like GL.h Instead, we rely on mesa3d to provide those headers: mesa3d has all the headers we need. Modifying the existing mesa3d package would not be easy; we'd have to differentiate whther we need only the headers or the full package. The meas3d Config.in and .mk are already quite non-trivial that adding such a feature would render them even more illegible. So, we introduce mea3d-headers as a new package, that is in fact just mesa3d with a much simplified Config.in and .mk, that other OpenXXX providers may select if they do not provide the OpenXXX headers. Note: we're not installing GLES3 headers, because what Buildroot currently calls libgles is in fact libgles2; we have no way to specify that we have libgles3. So, we just install headers for GLES and GLES2. [Thomas: - Wrap Config.in help text to a reasonable length. - Don't rely on mesa3d to provide mesa3d-headers: they should be mutually exclusive. Instead, error out if both packages are selected. - Take into account the update of mesa3d to 10.4.5. - Don't copy each header file individually, use a cp -dpfr call to copy entires header files directories.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-10 21:01:10 +01:00
define MESA3D_HEADERS_INSTALL_STAGING_CMDS
$(foreach d,$(MESA3D_HEADERS_DIRS),\
cp -dpfr $(@D)/include/$(d) $(STAGING_DIR)/usr/include/ || exit 1$(sep))
$(MESA3D_HEADERS_INSTALL_DRI_PC)
package/mesa3d-headers: new package Some OpenGL/EGL/GLES/VG providers do not provide the corresponding headers, and rely on using "the headers provided by the distribution". In our case, we can not rely on such headers, because we are not a distribution, and we have no way to provide those headers (not even speaking about relying on the headers provided by hte host distribution, because they might well not be installed at all). Also, we can not rely on another package to provide those headers, because we can only have one provider enabled in any configuration. The Khronos group provides such headers, and they are the reference headers, but we can not realy use them: - most of them are not packaged: they are not versioned and not provided in a tarball, but as separately downloadable files; - those headers are anyway incomplete: there are headers not provided by Khronos, like GL.h Instead, we rely on mesa3d to provide those headers: mesa3d has all the headers we need. Modifying the existing mesa3d package would not be easy; we'd have to differentiate whther we need only the headers or the full package. The meas3d Config.in and .mk are already quite non-trivial that adding such a feature would render them even more illegible. So, we introduce mea3d-headers as a new package, that is in fact just mesa3d with a much simplified Config.in and .mk, that other OpenXXX providers may select if they do not provide the OpenXXX headers. Note: we're not installing GLES3 headers, because what Buildroot currently calls libgles is in fact libgles2; we have no way to specify that we have libgles3. So, we just install headers for GLES and GLES2. [Thomas: - Wrap Config.in help text to a reasonable length. - Don't rely on mesa3d to provide mesa3d-headers: they should be mutually exclusive. Instead, error out if both packages are selected. - Take into account the update of mesa3d to 10.4.5. - Don't copy each header file individually, use a cp -dpfr call to copy entires header files directories.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-10 21:01:10 +01:00
endef
$(eval $(generic-package))