On 06/10/2023 15:31, Hendrik Leppkes wrote:
On Fri, Oct 6, 2023 at 3:07 PM Timo Rothenpieler <t...@rothenpieler.org> wrote:
On 06/10/2023 14:29, Hendrik Leppkes wrote:
On Sun, Oct 1, 2023 at 1:39 PM Timo Rothenpieler <t...@rothenpieler.org> wrote:
On 01.10.2023 04:06, James Almer wrote:
Fixes compilation after 05f8b2ca0f7e28775837a572c65ce9218f534ee2
It's expected behaviour to break compilation with random inter-release
versions of ffnvcodec.
It's only reliable exactly on release versions.
But isn't the point that there is no release version of ffnvcodec that
I can use to build this?
And that it has no check to limit building it, and will always fail
with release versions?
I don't understand what you mean.
Right now, it only works with nv-codec-headers master.
I will make a new release there very soon.
You say that its expected to break with inter-release versions of
ffnvcodec, but this is the opposite, it breaks with the release
version and works with git versions. So I'm not sure I understand what
you are saying.
No, with any old release version, configure correctly refuses to use them.
It's only broken with master versions after the last release, up to the
patch that added the function.
Requiring a non-released version of a dependency was obviously a
gigantic oversight with the original patch, and as a result master is
currently broken for any reasonable setup avoiding those
"inter-release versions".
master temporarily requiring a development-version of the headers wasn't
an oversight, that was the intended outcome of the update, and was done
exactly in that fashion many times before.
I'm quite confused why this specific instance suddenly causes so much upset.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
