Re: Error do_compile libepoxy

[Trevor Woerner <twoerner@gmail.com>]

On Mon 2018-01-22 @ 10:12:27 AM, Andrea Galbusera wrote:
> I'll try to follow up with a patch to meta-raspberrypi and
> possibly upstream to userland. In the end, I don't think libepoxy is
> the right place to explicitly put the change. What's your opinion
> here?

If I write C code, and in one of my C source files I use the function
XOpenDisplay(), then I'm of the opinion that (to be correct) this source file
should also #include <X11/Xlib.h> directly, and not depend on X11/Xlib.h being
included as a by-product of some other #include somewhere randomly up the
chain.

On the other hand, if I call function xyz() (and therefore #include <xyz.h>)
and xyz() calls XOpenDisplay(), then I would expect xyz.h to #include
<X11/Xlib.h> and not expect me to track down the header file for
XOpenDisplay() myself.

In my opinion the libepoxy code would be the right place to correct the
missing header file if it is calling XOpenDisplay() directly.

> Once more, looking at Khronos registry [3], which I learned being the
> right upstream reference for such an header, expected X11 includes are
> there, while, as said, they are missing in userland eglplatform.h.
> Unfortunately userland community does not seem to be very keen to
> update their includes even though Khronos published more up to date
> versions.
> 
> [3] https://www.khronos.org/registry/EGL/api/EGL/eglplatform.h

If you follow that link, the Xlib #includes in that very file are marked
"tentative"! Therefore I think the userland people can be excused from not
jumping on a request to add them.

Besides, let's say we don't add the #include to libepoxy and get the userland
people to add it in their header, then, 6 months later, Khronos votes on this
"tentative" issue and decides not to include them. userland would then remove
them from its headers, and we'd be right back where we are now: with C code
that uses a function but doesn't also include its relevant header directly.