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 13:01:10 -07: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...
|
2021-01-14 13:59:42 -07:00
|
|
|
MESA3D_HEADERS_VERSION = 20.3.3
|
2015-03-15 10:10:02 -06:00
|
|
|
MESA3D_HEADERS_SOURCE = mesa-$(MESA3D_HEADERS_VERSION).tar.xz
|
2017-03-04 12:54:56 -07:00
|
|
|
MESA3D_HEADERS_SITE = https://mesa.freedesktop.org/archive
|
2018-04-02 08:57:58 -06:00
|
|
|
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 13:01:10 -07:00
|
|
|
MESA3D_HEADERS_LICENSE = MIT, SGI, Khronos
|
2020-11-03 10:16:29 -07:00
|
|
|
MESA3D_HEADERS_LICENSE_FILES = docs/license.rst
|
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 13:01:10 -07:00
|
|
|
|
|
|
|
|
# Only installs header files
|
|
|
|
|
MESA3D_HEADERS_INSTALL_STAGING = YES
|
|
|
|
|
MESA3D_HEADERS_INSTALL_TARGET = NO
|
|
|
|
|
|
|
|
|
|
MESA3D_HEADERS_DIRS = KHR
|
|
|
|
|
|
|
|
|
|
ifeq ($(BR2_PACKAGE_HAS_LIBGL),y)
|
2015-02-10 13:01:11 -07:00
|
|
|
|
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 13:01:10 -07:00
|
|
|
MESA3D_HEADERS_DIRS += GL
|
2015-02-10 13:01:11 -07:00
|
|
|
|
|
|
|
|
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
|
2019-10-23 00:22:19 -06:00
|
|
|
sed -e 's:@VERSION@:$(MESA3D_HEADERS_VERSION):' \
|
|
|
|
|
package/mesa3d-headers/dri.pc \
|
2015-02-10 13:01:11 -07:00
|
|
|
>$(@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 \
|
2017-02-15 08:30:47 -07:00
|
|
|
$(STAGING_DIR)/usr/lib/pkgconfig/dri.pc
|
2015-02-10 13:01:11 -07:00
|
|
|
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 13:01:10 -07:00
|
|
|
|
|
|
|
|
ifeq ($(BR2_PACKAGE_HAS_LIBEGL),y)
|
|
|
|
|
MESA3D_HEADERS_DIRS += EGL
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(BR2_PACKAGE_HAS_LIBGLES),y)
|
|
|
|
|
MESA3D_HEADERS_DIRS += GLES GLES2
|
|
|
|
|
endif
|
|
|
|
|
|
2018-10-20 16:14:34 -06:00
|
|
|
ifeq ($(BR2_PACKAGE_HAS_LIBOPENCL),y)
|
|
|
|
|
MESA3D_HEADERS_DIRS += CL
|
|
|
|
|
endif
|
|
|
|
|
|
2015-02-10 13:01:11 -07:00
|
|
|
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 13:01:10 -07:00
|
|
|
define MESA3D_HEADERS_INSTALL_STAGING_CMDS
|
|
|
|
|
$(foreach d,$(MESA3D_HEADERS_DIRS),\
|
|
|
|
|
cp -dpfr $(@D)/include/$(d) $(STAGING_DIR)/usr/include/ || exit 1$(sep))
|
2015-02-10 13:01:11 -07:00
|
|
|
$(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 13:01:10 -07:00
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
$(eval $(generic-package))
|