[FFmpeg-devel] [PATCH 1/2] configure: Rename wincrypt to advapi32 for consistency with existing uses of check_lib
alevinsn_dev at levland.net
Tue Oct 31 21:40:15 EET 2017
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"
>> -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"
>> @@ -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.
More information about the ffmpeg-devel