[FFmpeg-devel] [PATCH 1/2] configure: Rename wincrypt to advapi32 for consistency with existing uses of check_lib

[Aaron Levinson]

On 10/31/2017 11:44 AM, Hendrik Leppkes wrote:
> On Tue, Oct 31, 2017 at 6:50 PM, Aaron Levinson
> <alevinsn_dev at levland.net> wrote:
>> Signed-off-by: Aaron Levinson <alevinsn_dev at levland.net>
>> ---
>>   configure | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/configure b/configure
>> index ea22d692b9..572299c9d3 100755
>> --- a/configure
>> +++ b/configure
>> @@ -3327,7 +3327,7 @@ avformat_deps="avcodec avutil"
>>   avformat_suggest="libm network zlib"
>>   avresample_deps="avutil"
>>   avresample_suggest="libm"
>> -avutil_suggest="clock_gettime libm libdrm libmfx opencl user32 vaapi videotoolbox corefoundation corevideo coremedia wincrypt"
>> +avutil_suggest="clock_gettime libm libdrm libmfx opencl user32 vaapi videotoolbox corefoundation corevideo coremedia advapi32"
>>   postproc_deps="avutil gpl"
>>   postproc_suggest="libm"
>>   swresample_deps="avutil"
>> @@ -5839,7 +5839,7 @@ check_builtin stdatomic_h stdatomic.h "atomic_int foo, bar = ATOMIC_VAR_INIT(-1)
>>
>>   check_lib ole32    "windows.h"            CoTaskMemFree        -lole32
>>   check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
>> -check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom       -ladvapi32
>> +check_lib advapi32 "windows.h wincrypt.h" CryptGenRandom       -ladvapi32
>>   check_lib psapi    "windows.h psapi.h"    GetProcessMemoryInfo -lpsapi
>>
>>   enabled appkit       && check_apple_framework AppKit
> 
> advapi32 contains many more things, while wincrypt refers to the name
> of the crypt header specifically, so wincrypt seems a bit more correct
> to me.
> 
> - Hendrik

I'm aware of this, but it seems to me either we use an approach that has 
many different check_lib statements for various API classes, even if the 
same library is used for each, or we have a single check_lib statement 
that picks a frequently used API from each library.  For example, how 
did someone arrive at CoTaskMemFree for ole32 when there are plenty of 
other APIs implemented in ole32?  The same goes for CommandLineToArgvW 
in shell32.  I could add a general advapi32 check_lib statement in 
addition to wincrypt, but the result will be the same--the addition of a 
dependency on advapi32.  Also, if the argument is, we want to make sure 
that we are using a specific version of advapi32 that supports 
CryptGenRandom, I could see that applying to a relatively new Win32 API, 
but CryptGenRandom has been around since Windows XP, and it is just as 
good as most APIs implemented in advapi32 for being the "principal" API 
associated with advapi32.  Adding a dependency on a component named 
"wincrypt", when all we want is access to the Registry APIs, I think is 
a bit misleading.

Aaron Levinson