[FFmpeg-devel] [PATCH] libx264: support for BUILD >= 63

Måns Rullgård mans
Thu Sep 18 00:03:24 CEST 2008


Aurelien Jacobs <aurel at gnuage.org> writes:

> Stefano Sabatini wrote:
>
>> On date Wednesday 2008-09-17 13:24:03 +0200, Frans de Boer encoded:
>> > On Wed, 2008-09-17 at 13:01 +0200, Dominik 'Rathann' Mierzejewski wrote:
>> > > On Wednesday, 17 September 2008 at 12:29, M?ns Rullg?rd wrote:
>> > > > 
>> > > > Stefano Sabatini wrote:
>> > > > > On date Tuesday 2008-09-16 23:52:50 +0100, M?ns Rullg?rd encoded:
>> > > > >> Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:
>> > > > >>
>> > > > >> > On date Tuesday 2008-09-16 11:28:56 +0200, Stefano Sabatini encoded:
>> > > > >> >> On date Tuesday 2008-09-16 09:24:40 +0100, M?ns Rullg?rd encoded:
>> > > > >> >> > Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:
>> > > > >> > [...]
>> > > > >> >> > It's always been expected that uses should have a
>> > > > >> >> > recent version of libraries they build FFmpeg
>> > > > >> >> > against.  Testing every little thing would become
>> > > > >> >> > such a chore.
>> > > > >> >>
>> > > > >> >> We know which version we need, and a simple check in
>> > > > >> >> the configure should ensure that the user is compiling
>> > > > >> >> against it.
>> > > > >> >>
>> > > > >> >> > > And while we're at it we could assert(X264_BUILD ==
>> > > > >> >> > > x264_build()) in the init code (assuming that
>> > > > >> >> > > function is implemented).
>> > > > >> >> >
>> > > > >> >> > It a little harsh with assert(), wouldn't you say?
>> > > > >> >> > In fact, this shouldn't be needed at all, assuming
>> > > > >> >> > libx264 uses correct shared library versioning.
>> > > > >> >>
>> > > > >> >> See my other mail in response to Dark Shikari, but I
>> > > > >> >> have not a strong opinion on this, the configure check
>> > > > >> >> may be sufficient.
>> > > > >> >
>> > > > >> > Attached there is a first experiment with check_version.
>> > > > > [...]
>> > > > >> Rejected.  It doesn't work if cross-compiling.  It may have other
>> > > > >> faults too; I didn't check carefully.  Besides, I don't think this
>> > > > >> check is necessary.
>> > > > >
>> > > > > Would be a solution using pkg-config acceptable?
>> > > > 
>> > > > No.  pkg-config only leads to misery.  Did you know that every time
>> > > > someone uses pkg-config, a child in Africa dies?
>> > > 
>> > > Don't be ridiculous. I'm sure a solution using pkg-config with
>> > > a fallback to some other method if pkg-config is not available
>> > > is acceptable.
>
> If we have a clean fallback to some other method, we don't need the
> pkg-config method anymore...

Quite.

>> The only alternative I can see for detecting the header version is to
>> grep the 264.h header, which leads to a very ad-hoc solution, or not
>> to support the version check at all, [...]
>
> Maybe something as simple as doing a check_cpp on the following code:
>
> #include <x264.h>
> #if X264_BUILD < 63
> #error "outdated x264"
> #endif
>
> IIRC, #error is not standard, but I guess any compiler which don't
> support it will just error out because of the unknown token, and
> thus, will also have the desired effect in this specific case.

#error is C99.

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




More information about the ffmpeg-devel mailing list