[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