The options USE_INLINE_TREES, SHOW_DIRECTORIES and HTML_ALIGN_MEMBERS
became obsolete with doxygen 1.8.1 (releaded 2012-05-19). The generated
outpu for older doxygen versions should not change since they were set
to the default value.
Documentation includes only the externally visible API of the installed
headers.
Based on a patch by Anton Khirnov <anton@khirnov.net>.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This adds support for building on Plan 9 x86-32. The compat/plan9
directory contains these items:
- replacements for the 'head' and 'printf' shell commands
- wrapper for main() to disable FPU exceptions
Larger required changes to the system are described in the
documentation.
Signed-off-by: Mans Rullgard <mans@mansr.com>
In addition to the recent tables mess, the AVOption defaults behavior
changed, so an old lavc used with a new lavu will get completely messed
up defaults.
Make av_pix_fmt_descriptors table static on next major bump.
Making the table public is dangerous, since the caller has no way to
know how large it actually is. It also prevents adding new fields to
AVPixFmtDescriptor without a major bump.
The current API where the plain size is exposed is not of much
use - in most cases it is allocated dynamically anyway.
If allocated e.g. on the stack via an uint8_t array, there's no
guarantee that the struct's members are aligned properly (unless
the array is overallocated and the opaque pointer within it
manually aligned to some unspecified alignment).
Signed-off-by: Martin Storsjö <martin@martin.st>
It has not worked for anything other than fringe codecs (asv1/2, mdec,
mjpeg[b]) since about 2003 and nobody ever noticed or complained. This
sufficiently proves that there are no users of this option who have a
clue of what they are doing, so it is completely useless.
This practice is not supported by the MinGW developers, and even requires
patching the MinGW runtimes in newer versions. Furthermore, we now support
build with MSVC, so this section is rendered useless.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>