On Tue, Feb 2, 2021 at 2:47 PM Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote:
>
> Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
> At the same time drm.h pulls a lot of unneeded symbols.
>
> Add new guard DRM_FOURCC_STANDALONE, which when set will use local
> declaration of said symbols.
>
> When used on linux - this is a trivial but only when building in strict c99
> mode. One is welcome to ignore the warning, silence it or use c11. If neither
> of the three is an option, then do _not_ set the new guard.
>
> Cc: James Park <james.park@xxxxxxxxxxxxxxxx>
> Cc: Pekka Paalanen <pekka.paalanen@xxxxxxxxxxxxx>
> Cc: Simon Ser <contact@xxxxxxxxxxx>
> Signed-off-by: Emil Velikov <emil.l.velikov@xxxxxxxxx>
> ---
> As mentioned before - there's little point in having yet another header
> since keeping those in sync has been a PITA in the past.
> ---
> include/uapi/drm/drm_fourcc.h | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 6f0628eb13a6..c1522902f6c9 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -24,7 +24,26 @@
> #ifndef DRM_FOURCC_H
> #define DRM_FOURCC_H
>
> +/*
> + * Define DRM_FOURCC_STANDALONE you're interested only FOURCC and do not want
> + * to pull drm.h into your application.
> + */
> +#ifdef DRM_FOURCC_STANDALONE
> +#if defined(__linux__)
> +
> +#include <linux/types.h>
> +
> +#else /* One of the BSDs */
> +
> +#include <stdint.h>
> +typedef uint32_t __u32;
> +typedef uint64_t __u64;
> +
> +#endif /* __linux __ */
> +
> +#else
> #include "drm.h"
> +#endif /* DRM_FOURCC_STANDALONE */
>
> #if defined(__cplusplus)
> extern "C" {
> --
> 2.30.0
>
One of my earlier solutions similarly would have forced people to deal
with duplicate typedefs, and we arrived at the current solution
because we didn't want to burden anyone with that. I feel like having
the extra include-guarded file is the lesser of evils. If it helps the
patch go through, then I'd drop my preference but I really think the
current solution is better.
- James
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
