On Wed, 2 Nov 2011, Diego Biurrun wrote:
On Wed, Nov 02, 2011 at 01:25:27PM +0100, Reinhard Tartler wrote:
On Mi, Nov 02, 2011 at 13:14:49 (CET), Martin Storsjö wrote:
On Wed, 2 Nov 2011, Diego Biurrun wrote:
---
configure | 21 +--------------------
libavutil/internal.h | 28 ----------------------------
2 files changed, 1 insertions(+), 48 deletions(-)
This is useful whenever we move public functions from one library to
another. Currently, there are no such ones, since the cases where it was
used was removed after the last major bump, but if we want to move more
functions in an upcoming bump, we'll need this again.
How often does this really happen?
We do move functions from e.g. lavc to lavu every now and then, or more
seldomly, move stuff from lavf to lavc/lavu. Last time Luca suggested
moving the lock manager api from lavc to lavu two days ago.
Sure, we could just revert the removal if we need to move other
functions again, of course, but removing it breaks scripts that use
--disable-symver for the periods of time when it isn't present.
I wouldn't mind putting it back if/when the need for it arises again.
Note that in the meantime it confuses Doxygen into issuing warnings.
We should at least deprecate that configure switch for one release
before actually removing them.
We've never handled configure switches in this way before.
Not sure how often we've removed switches before.
As a concrete point for this, there's a number of scripts for building
libav for android, and many of these use --disable-symver (without it, the
binaries don't work properly) if using shared libraries. If we remove it,
all those scripts need updating (and updating once again if we readd it
later again).
And to preempt the following discussion on whether this should be
automatically detected or not - that was discussed in december, and the
conclusion was that it's ok with a configure switch for this issue, since
the android runtime linker might start supporting versioned symbols at
some point (and we can't detect the behaviour of the runtime linker from
the build system).
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
