Migration experiences / Comparison RUNTIME_DEPENDENCY_SET vs. fixup_bundle (BundleUtilities)

Usage
5

Regarding how to exclude the Windows system libraries, CMake Professional (18th ed) gives an example of adding

	POST_EXCLUDE_REGEXES
		[[.*/system32/.*\.dll]]

to the install(RUNTIME_DEPENDENCY_SET call, but using this I saw many .dlls from the system32 folder being copied to the final package. When I use [[.*system32.*\.dll]] instead it seems to work. I also tried \ instead of / but that also didn’t work. What’s the correct way of specifying a directory separator here?

Basically, bundling based on RUNTIME_DEPENDENCY_SET now works on my project - with one minor exception. I would like to bundle a different version of onnxruntime.dll than what is contained in system32 - but RUNTIME_DEPENDENCY_SET always searches in sytem32 first (and of course finds something there) - but I don’t want to include any dlls from system32 (see above), so no version of onnxruntime is included at all. There currently seems no way to address this from within RUNTIME_DEPENENCY_SET installation, I guess I’ll have to install the onnxruntime manually? This does work as I would expect it with fixup_bundle - I believe fixup_bundle only searches in the specified directories? I don’t really get the use case for under Windows searching under system32 first - shouldn’t .dll’s from there never be included anyway? Is this just for “filtering out” libraries that are coming from the system?

Open issues:

  • Find correct way of specifying directory separator in POST_EXCLUDE_REGEXES (or simply ignore and skip every .dll that has system32 somewhere in the full path, I don’t expect any future libraries to have this string in their names or so).
  • Find a way to skip Windows / system32 directory for a shared library / work around it by installing dll file directly via install(FILES...)

To sum up my findings regarding differences:

  1. RUNTIME_DEPENDENCY_SET:
    • appears a bit more flexible regarding specific libraries to be explicitly excluded
    • searches transitively for dependencies, which can be an advantage but also a disadvantage since unwanted system libraries have to be excluded manually
    • less flexible regarding search paths - if a .dll exists in system32, no alternative can be used, the shared library has to be “manually” installed.
    • much faster than (2) (~ 30sec total cpack time on my machine)
  2. BundleUtilities fixup_bundle in contrast:
    • allows explicitly specifying the searched directories (and only those are searched, in contrast to (1), where e.g. under windows, C:\Windows and C:\Windows\system32 are always searched)
    • requires a pre-set-up environment to be able to resolve dependencies (such as a the “… Command Prompt for VS 20xx” provide), otherwise it will not do any dependency resolution (without reporting any error)
    • significantly slower than (1) (~ 4min 20sec total cpack time on my machine)