[FFmpeg-devel] On in-tree external headers

Mark Thompson sw at jkqxz.net
Sun Nov 5 16:24:37 EET 2017


On 30/10/17 19:51, Mark Thompson wrote:
> 
> Hi all,
> 
> The recent submission of AMD AMF patches including a builtin header prompted me to think further about what external API headers should actually be included in the tree.
> 
> For the AMD headers (like V4L2 previously), it seems entirely silly to include them - they are available upstream in a free form which can easily be packaged and available on any build machine to use.
> 
> However, there is the problem that this in some sense places them second-class to the Nvidia implementation, which includes all headers in-tree and automatically enables itself - any normal build for x86 will include Nvidia support by default if the user doesn't explicitly disable it.  The effect of that is essentially that the ffmpeg project is facilitating Nvidia's anti-open behaviour by including the headers, which is I think something we really shouldn't be doing.
> 
> So: can we please precisely codify under what circumstances external headers should be included in the ffmpeg tree?
> 
> As an initial position for consideration, I propose "no external headers may be included in the ffmpeg tree".  That is, the contents of the compat/ directory should only be OS/compiler compatibility workarounds, not any functional headers.
> 
> Would anyone like to propose an alternative position?  (Precisely defined - "what we have now" would need some clarification of what that actually means so that we can apply it consistently to future requests.)
> 
> I also ask that, whatever discussion here ends up with, the voting committee should vote to ratify it so that we don't have to discuss it again every time someone proposes including headers.

No alternatives were proposed, so I would like to call a vote on adopting the following clear policy:

"No external headers may be included in the ffmpeg tree."

(A corresponding documentation change is below, which tries to cover the related packaging point.)

Does anybody want to offer any other options to vote on?  I suggest starting the vote tomorrow, to run for one week.

Thanks,

- Mark


diff --git a/doc/developer.texi b/doc/developer.texi
index a7b4f1d737..3aeb727729 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -381,6 +381,15 @@ Never write to unallocated memory, never write over the end of arrays,
 always check values read from some untrusted source before using them
 as array index or other risky things.
 
+ at subheading External headers
+Do not include external headers directly in FFmpeg.  Most packages provide
+suitable headers and linkable libraries when installed, and these should be
+used.  References to external packages in configure should use pkg-config
+if possible to find paths and options - ad-hoc build tests with hard-coded
+paths are to be avoided, but can be used if there is no other possibility.
+If an external package does not provide usable headers or libraries then
+please add directions for how to use it to the documentation.
+
 @subsection Documentation/Other
 @subheading Subscribe to the ffmpeg-cvslog mailing list.
 It is important to do this as the diffs of all commits are sent there and


More information about the ffmpeg-devel mailing list