Le tridi 23 messidor, an CCXXV, Clement Boesch a écrit : > As a public API? With the .c include "trick"? avpriv_? I don't know what's > the current consensus, but people never seem to agree about the path to > take in that regard. You'll also get the discussion about merging all the > libs into one.
Well, you brought it up, not me :-) > If you don't want to loose motivation, you're probably better of sending Nit: to loose =~ to set free != to lose =~ to misplace. > working patches with duplication first. But maybe that's what you had in > mind anyway. I will not make difficulties for these changes, as they address code that is already somewhat duplicated and quite tricky. But at some point we will need to address the issue. I think that even if nobody starts to implement anything right away, we should discuss the question and decide the direction we want to go. At the very least, it would alleviate bikeshedding for future patches and make it safer for anybody to start working on something without fear of being eventually rejected. So I would like to put the following motion to discussion: Starting roughly three months from now, linking (including dynamically at run time) with different versions of the libraries will not be supported. Only linking with the exact same versions (source code and build options) will be supported. This applies even if nothing is actually implemented to enforce it (but it would be better to have something). It is far from a complete solution, but at least it gives a direction. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
