[FFmpeg-devel] [PATCH] configure: improve logic and checks for nvenc

[Timo Rothenpieler]

> 2016-08-31 15:26 GMT+02:00 Timo Rothenpieler <timo at rothenpieler.org>:
>>> 2016-08-31 15:03 GMT+02:00 Timo Rothenpieler <timo at rothenpieler.org>:
>>>> Forgot this, the idea with my approach is to handle the case where
>>>> --enable-nvenc is requested, but the compile-check fails.
>>>
>>>> Just silently disabling it then seems wrong.
> 
> It's what FFmpeg does for more than a decade.

I'll follow along with nvenc for now, and might try to tackle it at a
more general level.

>>> But this is what we do for all auto-detected features except xcb. If changing
>>> this comes at the price of far more complicated checks, I suggest we keep
>>> the current logic.
>>
>> Hm, just silently disabling stuff that's explicitly requested to be
>> enabled via enable seems broken.
>> It might also result in builds which show a feature to be enabled in the
>> configure line they show, while it's actually disabled because of a
>> failed check/missing library.
> 
> This is exactly why I ask Zeranoe (and Alexis) since several years to
> remove "--enable-zlib --enable-bzlib" from their configure lines, so far
> my success was limiited;-(
> 
> I'd like to repeat that if this new feature comes at the price of
> significantly more complicated checks in the configure script,
> we should probably not change the established logic.
> (Correct me if I misremember: It was tried already but resulted in
> completely broken configure?)
> 
> Carl Eugen

The idea I'd have for this it to simply store a second variable while
parsing the enable/disable options, which states user_enabled/user_disabled.
That way checking for it becomes a mere

user_enabled feature && disabled feature && die "..."

Which could even be reduced further by introducing a function that does
exactly that.

Could even go over all disabled features at the end of configure, and
throw a warning or even an error in case something is user_enabled but
finally set to disabled.