[FFmpeg-devel] [PATCH] hwcontext_vulkan: make 2 public functions always available
Niklas Haas
ffmpeg at haasn.xyz
Fri Dec 3 14:59:33 EET 2021
On Thu, 02 Dec 2021 19:13:17 +0100 Andreas Rheinhardt <andreas.rheinhardt at outlook.com> wrote:
> Lynne:
> > The issue is that if ffmpeg is compiled without Vulkan, and an API
> > user includes and uses the functions exposed in hwcontext_vulkan.h,
> > then a linking error will happen, as the hwcontext_vulkan.c file has
> > not been compiled.
> >
> > Move the functions to another file, and make it always compiled. The
> > functions do not use any Vulkan functions.
> >
> > Patch attached.
> >
> >
>
> 1. Isn't a linking error exactly what is intended in such cases?
> 2. And even if not: Actually compiling the whole implementation is
> unnecessary; in such cases we typically #if everything away (e.g. in
> your case: it will always return NULL).
> 3. The hwcontext_vulkan.h header requires vulkan system headers; you
> can't compile this without it.
Hi, I have a motivating use case: a single header library which needs to
conditionally use these functions only if they're supposed. My first
instinct was to test if the header is available/included, but that
doesn't work, because ffmpeg unconditionally installs it even if it's
not compiled (IMO wrong behavior).
If the only way to know whether or not the header works, is to perform a
build-time check to see if the functions link, that uncomfortably shifts
responsibility onto the API user of my library to perform this check on
their end before including my (single header) library.
This was one proposed work-around, which is to make them always link but
return a runtime error if FFmpeg was compiled without vulkan support.
I agree that in this case the entire file should be #if'd out and the
signatures implemented by stub functions that only return the necessary
error, with no build-time dependency on vulkan.h.
More information about the ffmpeg-devel
mailing list