[Help Appreciated] `OpenCV` configuration variables

[helmesjo]

I'm currently in the process of packaging OpenCV which comes with a plethora of configuration variables, and I've started extracted some of them here from eg. cvconfig.h.in (there are others, but this appears to be the main one to get started). It's not clear to me ATM which are OpenCV-specific and which are generic variables (if any), but I figured I'll list them here if anyone wants to chip in on figuring out how each check is determined true/false:

cvconfig.h.in

• [ ] ENABLE_INSTRUMENTATION
• [ ] HAVE_AVIF
• [ ] HAVE_CLAMDBLAS
• [ ] HAVE_CLAMDFFT
• [ ] HAVE_CLP
• [ ] HAVE_CUBLAS
• [ ] HAVE_CUDA
• [ ] HAVE_CUDNN
• [ ] HAVE_CUFFT
• [ ] HAVE_D3D10
• [ ] HAVE_D3D11
• [ ] HAVE_D3D9
• [ ] HAVE_DIRECTX
• [ ] HAVE_DIRECTX_NV12
• [ ] HAVE_DYNLINK_NVCUVID_HEADER
• [ ] HAVE_EIGEN
• [ ] HAVE_GDAL
• [ ] HAVE_GDCM
• [ ] HAVE_HALIDE
• [ ] HAVE_HPX
• [ ] HAVE_INTTYPES_H 1
• [ ] HAVE_IPP
• [ ] HAVE_IPP_ICV
• [ ] HAVE_IPP_IW
• [ ] HAVE_IPP_IW_LL
• [ ] HAVE_JASPER
• [ ] HAVE_JPEG
• [ ] HAVE_LAPACK
• [ ] HAVE_NVCUVENC
• [ ] HAVE_NVCUVID
• [ ] HAVE_NVCUVID_HEADER
• [ ] HAVE_OPENCL
• [ ] HAVE_OPENCL_D3D11_NV
• [ ] HAVE_OPENCL_STATIC
• [ ] HAVE_OPENCL_SVM
• [ ] HAVE_OPENEXR
• [ ] HAVE_OPENGL
• [ ] HAVE_OPENJPEG
• [ ] HAVE_OPENVX
• [ ] HAVE_PNG
• [x] HAVE_PTHREAD
• [ ] HAVE_PTHREADS_PF
• [ ] HAVE_QUIRC
• [ ] HAVE_SPNG
• [ ] HAVE_TBB
• [ ] HAVE_TIFF
• [ ] HAVE_VA
• [ ] HAVE_VA_INTEL
• [ ] HAVE_VULKAN
• [ ] OPENCV_TRACE
• [ ] WORDS_BIGENDIAN

cv_cpu_config.h.in

• [ ] OPENCV_CPU_BASELINE_DEFINITIONS_CONFIGMAKE
  • Populated by OpenCVCompilerOptimizations.cmake
• [ ] OPENCV_CPU_DISPATCH_DEFINITIONS_CONFIGMAKE
  • Populated by OpenCVCompilerOptimizations.cmake

[boris-kolpackov]

A couple of notes from a cursory review:

1. OPENCV_* ones are not likely to belong to autoconf (but it's possible they could be derived from some more general checks).

2. Quite a few ones like HAVE_EIGEN, HAVE_JPEG, etc., appear to signal the use of a dependency and also don't belong in autoconf, naturally. The correct way to handle these (assuming they are optional dependencies) is with configuration variables.

3. It makes sense before implementing any check to make sure we don't already have a differently-named ones with equivalent functionality (and which can therefore be reused). I am pretty sure we already have equivalent for WORDS_BIGENDIAN.

4. Finally, in our experience, it's quite common for there to be a macro defined in config.h.in that is actually not used anywhere in the codebase (i.e., people routinely stop using some functionality but forget to cleanup their config.h.in). So it makes sense to confirm a check is actually used before spending time on implementing it.