Thanks a lot for the great suggestion! The option looks very promising. I'll check several corner cases and return back with feedback.

Hi

I found some issues with this PR:

1. Build failed if Ninja generator is used. Only build with the MSVC generator succeeded. I googled and found this.
2. I built OpenCV with and without CUDA_ENABLE_DELAYLOAD and also build test CUDA-apps. I then ran it on two Windows machines (with and without CUDA installed), and found no difference in apps behaviour on both machines. Dependency checking shows that the only one difference is delayed loding of CUDA-dlls by opencv_cudaarithm460.dll (see screenshots).

opencv_cudaarithm460.dll built without CUDA_ENABLE_DELAYLOAD:

opencv_cudaarithm460.dll built with CUDA_ENABLE_DELAYLOAD:

@stopmosk Please show your test app code and OpenCv build options pefore and after the patch.

Hi,

Thanks for your comment!

First, regarding the issue with Ninja: From the link you added, I suspect that Ninja mixes something between the respective import libraries (.lib files) and the delay-loaded DLLs. Unluckily, the /delayload flag requires the DLLs and not the LIBs, as already mentioned above. This can be easily fixed by only allowing MSCV inside the CMake scripts (i.e. adding an 'if not Ninja condition'), but we are open to investigate which additional flags are required for Ninja as well to support the flag there, too. Still, we never used Ninja and a quickly setup of CMake using Ninja with specified C and C++ compilers terminates with the error message

  The C++ compiler

    "C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.34.31933/bin/Hostx64/x64/cl.exe"

  is not able to compile a simple test program.

for unknown reasoning. The compiler is working fine (e.g. in combination with MSVC CMake builds) and it's unclear how to debug this. Is there a reference on how to compile OpenCV using Ninja on Windows? Unluckily, I found none by myself.

Regarding your second comment: This is exactly the expected behavior, only the CUDA DLLs are delay-loaded. Still, the cudaarithm DLL is not a good example for the benefit of this flag because - at least as far as I know - there is nothing inside this DLL that works without CUDA-supported hardware. I think the DNN module is a better example: Here, we can either use the CPU backend (supported on all machines), the OpenVINO backend (supported on machines with an OpenVINO supported CPU or GPU) or the CUDA backend. Obviously, the latter is supported on machines equipped with CUDA-compatible hardware only. Still if CUDA is activated while compiling OpenCV, the CUDA libraries always have to be distributed to all machines at runtime, even though they cannot be used at all. This is where the delay load option shines: Activate it and the whole CUDA functionality is available to devices that can use it, while all non-CUDA functionalities are still available on all machines, without needing a superfluous CUDA installation.

Great, thanks for approving 👍

@CSBVision Could you squash the commits to have clear merge history?

Generally yes; however I don't want to mess up something. The right command should be

git rebase -i HEAD~3 

or isn't it?

After git rebase -i HEAD~3 git opens a VIM window with

pick f5e9dfe64a Update OpenCVDetectCUDA.cmake
pick fdf67a4f5f Update OpenCVDetectCUDA.cmake
pick efc4f66e11 Update OpenCVDetectCUDA.cmake

where exiting shows Successfully rebased and updated refs/heads/patch-2. but git push shows everything is up to date. What am I missing?

1. Run again:

git rebase -i HEAD~3

2. Change 2nd and 3rd lines from pick to f (fixup):

pick f5e9dfe64a Update OpenCVDetectCUDA.cmake
f fdf67a4f5f Update OpenCVDetectCUDA.cmake
f efc4f66e11 Update OpenCVDetectCUDA.cmake

3. save and exit

4. git push ... with --force flag

5. PR's patch should be updated (1 commit is visible, +13 -0 lines changed).

Thanks @alalek , I hope it's correct now.