[FFmpeg-devel] [PATCH] fix compilation (was Re: r12489 broke all builds)

Reimar Döffinger Reimar.Doeffinger
Wed Mar 19 13:28:25 CET 2008

On Wed, Mar 19, 2008 at 11:49:13AM -0000, M?ns Rullg?rd wrote:
> By the above rule, any file that uses WORDS_BIGENDIAN should explicitly
> include config.h.  It so happens, that common.h is (or should be)
> documented to include config.h (when building FFmpeg), and avcodec.h
> can be relied on to include common.h.  However, there is no promise
> that bswap.h include any additional headers.

Rules are all nice and well, the problem is people tend to ignore them,
the no-implicit-includes rule means that those forgetting to include
some of the required headers are very likely to get compilation errors.

> A more realistic example is a file, let's call it mpeg12data.c, that includes,
> say, rational.h, and everything is fine.  One fine day, someone changes
> rational.h to require stuff from common.h, without adding the #include
> line.  Suddenly, mpeg12data.c fails to compile because it doesn't include
> common.h, and has no reason to do so, not directly using any of its symbols.

I do not consider (esp. one-time) compilation errors a big deal.
Either way I do not strongly favour either way, I just think that
headers-including-headers has a higher probability of "silent" failures,
which is why I just do not really like it, and in my own projects only
use it for non-obvious dependencies (e.g. I consider it obvious that
everything needs inttypes.h in my projects ;-) ).

> It is not reasonable that backwards compatible changes to a header file
> should require updating every source file that uses.  Just think for a
> moment about public API headers.

Public API headers are a different kind of thing I agree, though adding
includes in these without proper consideration is even worse.

Reimar D?ffinger

More information about the ffmpeg-devel mailing list