[Ffmpeg-devel] [PATCH][RFC] --enable/disable parsers

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> Hi
>
> On Sun, Jul 09, 2006 at 03:32:00AM +0100, M?ns Rullg?rd wrote:
>> Here is a patch that allow to enable/disable parsers individually and
>> independently of codecs.  With the patch in this form, certain
>> combinations of codecs and parsers will not build, and disabling the
>> parsers makes formats that require them unusable, so take it only for
>> the starting point for discussion I intended.
>> 
>> Is this something that would be desirable to pursue into something
>> more robust?  I can imagine situations where one might want parsers
>> without codecs (e.g. remuxing only), or codecs without parsers
>> (e.g. input is known to be properly framed).
>> 
>> I have also been experimenting with a system for finer control over
>> what gets built.  With this, it would be possible to forcibly enable
>> parsers for any codecs that are selected.
>> 
>> Has anyone got any comments on all this?
>
> yes, i do not like seperate #ifdefs around static functions
> its gccs job to drop them

Two reasons: 1) gcc prints warnings about unused static functions, and
2) it makes compilation faster.  The legitimacy of the warnings may of
course be debated, but the fact is that they are there, and I want the
code to be clean of warnings, even useless ones, so that real warnings
are not missed if they pop up.

> except that i like finer control over what gets build of course 

My grand plan is to make things like dsputil built only if some codec
needs it.  To arrive there in small steps it may be necessary to pass
some stages where certain obscure configure option combinations could
result in build errors.  The default configuration, as well as normal
variations, would of course always be working.  Is this objectionable
to anyone?  I'm afraid that the alternative is to do it all at in one
go, and that's not perfect either.

-- 
M?ns Rullg?rd
mru at inprovide.com