[FFmpeg-devel] Installing a safe config.h subset (was: Re: pixfmt.h installed header using HAVE_BIGENDIAN?)

Måns Rullgård mans
Sun Jan 17 16:47:20 CET 2010

Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

> On Sun, Jan 17, 2010 at 03:00:04PM +0000, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> > On Sun, Jan 17, 2010 at 02:35:50PM +0000, M?ns Rullg?rd wrote:
>> >> Michael Niedermayer <michaelni at gmx.at> writes:
>> >> 
>> >> >> config.h should be installed, or at the very very least a file that
>> >> >> contains the big_endian define, none of the arguments against
>> >> >> config.h installation apply to this define
>> >> 
>> >> I'll see about installing a sanitised subset of config.h.  We'll have
>> >> to rename the HAVE_ and CONFIG_ tokens in it though, or we'll be
>> >> clashing with others.
>> >
>> > :))))))))
>> One (bikeshed) issue though: where do we install this header?  We
>> currently install headers in $incdir/libav*/, but config.h applies to
>> all of them.
> A minor revision, to be able to just leave
> #include "config.h"
> in there we'd have to install it in all of them...

The old config.h will remain with everything unsuitable for the public
version.  However, we'll have to name the new one something other than
config.h, or #includes from within libavutil will go awry.  I'm
thinking of libavutil/avconfig.h.  This could be #included from
config.h to avoid changing every file in ffmpeg.

There is one more issue.  Do we care about the possibility for shared
libs to have a different configuration than what the header was
generated with?  Depending on what we put in the installed one, this
could be more or less of an issue.  There should be nothing
configurable that affects the ABI, so nothing major will break, but
apps using the symbols might not get what they're expecting.

I propose to only include things from the ARCH_ and HAVE_ sets, and
then only those which do not depend on the specific tools used to
build FFmpeg.  Some of these can be overridden by configure options,
but none of these affect the available functionality, only

Symbols describing the hardware should be safe (I'm ignoring people
changing their hardware without rebuilding).  System library
characteristics (available headers and functions) are different
matter.  These are relatively volatile and can become invalid through
a simple software update, so those parts are probably best left out of
the installed header.

If anyone feels this approach is insufficient or has problems, speak

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list