[FFmpeg-cvslog] r11202 - trunk/configure

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Wed, Dec 12, 2007 at 12:15:22PM -0500, Rich Felker wrote:
>> On Wed, Dec 12, 2007 at 11:57:11AM -0000, M?ns Rullg?rd wrote:
>> > I see.  Yes, that's probably possible, though I'd rather not spend time
>> > figuring out how to do it if we can get rid of these exports more easily.
>> 
>> Indeed. Despite the binutils bug, we should be visciously removing any
>> public global vars anyway. They have high program startup cost
>> regardless of what linking mode is used (copy relocations or textrels
>> in the main program).
>> 
>> If access to them is really needed, make a function that returns a
>> (hopefully const-qualified) pointer to the data. But I can't imagine
>> why a legitimate program would be peeking directly at these data
>> structures..
>
> some examples where this is currently used are
>
> av_log_level
> av_vlog
> currently we have wraper functions for these to set/get them
> originally i wanted to drop these functions, as can be seen by the
> #if LIBAVUTIL_VERSION_INT in log.{c,h}
> i guess we should just leave the more complex API or do you suggest
> that we change it to 2 functions to returning pointers to
> av_log_level and av_vlog?

I'd say remove the #ifdef around those functions and start using them.

> and then there are these first_avcodec like linked lists for formats
> and codecs these should be changed to some implementation
> independant access code like
>
> AVCodec avcodec_next(AVCodec *c){
>     if(!c) return first_avcodec;
>     else   return c->next;
> }

I see you've already taken care of these.

> i belive the above are the only cases of exported (non constant) variables

There's ffm_nopts too.  However, this one is an ugly hack at best, and
for now I think it would be OK to insist on static builds if anyone
wants to use it.

-- 
M?ns Rullg?rd
mans at mansr.com