[Buildroot] [PATCH 03/10 v7] package/mesa3d-headers: new package

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Sat Feb 14 09:09:23 UTC 2015

Dear Yann E. MORIN,

On Tue, 10 Feb 2015 21:01:10 +0100, Yann E. MORIN wrote:
> 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.
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998 at free.fr>
> ---
> Notes:
> It should not be possible to select both mesa3d *and* mesa3d-headers at
> the same time, but it is difficult to foresee the multiple combinations
> we may have, due to poor understanding on how binary drivers may behave
> and what they may require, as well as my own poor understanding of the
> GL stack(s).
> So I decided to just print a warning in that case, and just depend on
> mesa3d, which would ultimately provide the headers we are interested in
> anyway. This can be turned into an error if preferred.

Yes, I believe this should rather be an error. The expected users of
mesa3d-headers are proprietary OpenGL implementations, which have
normally no reason to co-exist with Mesa3D on a given system. So I'd
prefer this to be considered an error, and to not have mesa3d-headers
depend on mesa3d when both are enabled.

> +# Only installs header files
> +
> +
> +ifeq ($(BR2_PACKAGE_HAS_LIBGL),y)
> +endif
> +
> +ifeq ($(BR2_PACKAGE_HAS_LIBEGL),y)
> +endif
> +
> +ifeq ($(BR2_PACKAGE_HAS_LIBGLES),y)
> +endif
> +
> +endif
> +
> +	$(foreach d,$(MESA3D_HEADERS_DIRS),\
> +		for h in $(@D)/include/$(d)/*.h; do \
> +			$(INSTALL) -D -m 0644 $${h} $(STAGING_DIR)/usr/include/$(d)/$$(basename $${h}) || exit 1; \

Instead of doing a for for each header, what about using a plain cp
-dpfr like we do in many other packages?

Let me know if you agree with the proposed changes, I can quickly make
them while applying if you don't want to respin the entire patch series.


Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering

More information about the buildroot mailing list