Re: [QDVDAuthor-users] QDVDAuthor-users post from richard@mail.sheugh.com requires approval

[FeRD <fe...@gm...>]

On Sun, Apr 7, 2013 at 7:04 AM, QDVDAuthor <QDV...@us...
> wrote:

>
> If you look at local_ffmpeg.sh, it will pull a text file from my web
> page which specifies that ffmpeg version.
>
>
I'm actually curious as to the reasoning behind that. What's the intent in
having the ffmpeg version determined at compile-time? It seems to me that
would only *increase* the likelihood of build problems, honestly.

With ffmpeg's moving-target APIs and ABIs, version-compatibility is pretty
much intrinsically married to the consuming code. We've seen that time and
time again. So, seeing as any given revision of a codebase like qdvdauthor
was developed, tested, and API-targeted towards a specific ffmpeg release
(ideally), *that release's identity* (and location) should be encapsulated
directly alongside the code, since it's really the only ffmpeg version that
you can hope to promise compatibility with at build-time.

Swapping out a given ffmpeg release for a newer one in some process
external to the codebase (like, say, by updating that referral URL) risks
breaking things for anyone who's trying to build a revision of the
qdvdauthor code that wasn't tested against that new version. (Those people
may be backrev, but why would it be a good thing to *break* compilation of
previous revisions of the codebase?)

If a new ffmpeg release is synced to, then the necessary changes can be
checked in alongside the updated URL, so that anyone who checks out the
newest revision builds against the newer ffmpeg, and anyone who hasn't yet
gotten the latest changes continues to build against the ffmpeg release
that was tested with the code they have.

-FeRD