Parse linking dependencies and bundle dependencies from CMake output instead of hardcoding

[csmoe]

After some investigation, the most stable way to get those dependencies I could find is "grep" on the output of cmake cli output.

cmake can print its trace in json format(--trace-format=json-v1 --trace-expand), but the output still hard to use:

{
  "args": [
    "STATUS",
    "CEF Binary files:             chrome_elf.dll;d3dcompiler_47.dll;libcef.dll;libEGL.dll;libGLESv2.dll;snapshot_blob.bin;v8_context_snapshot.bin;vk_swiftshader.dll;vk_swiftshader_icd.json;vulkan-1.dll;dxil.dll;dxcompiler.dll"
  ],
  "cmd": "message",
  "file": "D:/cef/windows/archive_windows_x86_64/cmake/cef_macros.cmake",
  "frame": 2,
  "global_frame": 2,
  "line": 62,
  "time": 1737627651.4411716
}
{
  "args": [
    "STATUS",
    "CEF Resource files:           chrome_100_percent.pak;chrome_200_percent.pak;resources.pak;icudtl.dat;locales"
  ],
  "cmd": "message",
  "file": "D:/cef/windows/archive_windows_x86_64/cmake/cef_macros.cmake",
  "frame": 2,
  "global_frame": 2,
  "line": 63,
  "time": 1737627651.4411716
}

while the cli output is easy to "grep":

-- Standard libraries:         comctl32.lib;gdi32.lib;rpcrt4.lib;shlwapi.lib;ws2_32.lib;Advapi32.lib;dbghelp.lib;Delayimp.lib;ntdll.lib;OleAut32.lib;PowrProf.lib;Propsys.lib;psapi.lib;SetupAPI.lib;Shell32.lib;Shcore.lib;Userenv.lib;version.lib;wbemuuid.lib;WindowsApp.lib;winmm.lib
...
-- CEF Binary files:             chrome_elf.dll;d3dcompiler_47.dll;libcef.dll;libEGL.dll;libGLESv2.dll;snapshot_blob.bin;v8_context_snapshot.bin;vk_swiftshader.dll;vk_swiftshader_icd.json;vulkan-1.dll;dxil.dll;dxcompiler.dll
-- CEF Resource files:           chrome_100_percent.pak;chrome_200_percent.pak;resources.pak;icudtl.dat;locales

[xb284524239]

while the cli output is easy to "grep":

-- Standard libraries:         comctl32.lib;gdi32.lib;rpcrt4.lib;shlwapi.lib;ws2_32.lib;Advapi32.lib;dbghelp.lib;Delayimp.lib;ntdll.lib;OleAut32.lib;PowrProf.lib;Propsys.lib;psapi.lib;SetupAPI.lib;Shell32.lib;Shcore.lib;Userenv.lib;version.lib;wbemuuid.lib;WindowsApp.lib;winmm.lib
...
-- CEF Binary files:             chrome_elf.dll;d3dcompiler_47.dll;libcef.dll;libEGL.dll;libGLESv2.dll;snapshot_blob.bin;v8_context_snapshot.bin;vk_swiftshader.dll;vk_swiftshader_icd.json;vulkan-1.dll;dxil.dll;dxcompiler.dll
-- CEF Resource files:           chrome_100_percent.pak;chrome_200_percent.pak;resources.pak;icudtl.dat;locales

These informations are only output after the build, but we need to use them before the build, which is a contradiction.

[csmoe]

That's fine since libcef_dll_wrapper will be built before rust compilation.

[xb284524239]

cef-rs/sys/build.rs

Lines 72 to 97 in 74e4f14

	"windows" => {
	let sdk_libs = [
	"comctl32.lib",
	"delayimp.lib",
	"mincore.lib",
	"powrprof.lib",
	"propsys.lib",
	"runtimeobject.lib",
	"setupapi.lib",
	"shcore.lib",
	"shell32.lib",
	"shlwapi.lib",
	"user32.lib",
	"version.lib",
	"wbemuuid.lib",
	"winmm.lib",
	]
	.join(" ");
	let build_dir = cef_dll_wrapper
	.define("CMAKE_MSVC_RUNTIME_LIBRARY", "MultiThreaded")
	.define("CMAKE_OBJECT_PATH_MAX", "500")
	.define("CMAKE_STATIC_LINKER_FLAGS", &sdk_libs)
	.build()
	.display()
	.to_string();

Oh, I mean that when building the libcef_dll_wrapper, the linked runtime library is hard-coded. It should also be obtained from CMake. However, we can't get the CMake output before building the libcef_dll_wrapper.

[csmoe]

But libcef_dll_wrapper doesn't need those libs while compiling, don't know why they are listed here, I linked them with rust previously https://github.com/tauri-apps/cef-rs/pull/15/files#diff-2620be2afc249413fa14ee1f678c9c7ab8f0658f44f5c6d49cff57956c716debR27 cc @wravery

[wravery]

But libcef_dll_wrapper doesn't need those libs while compiling, don't know why they are listed here, I linked them with rust previously https://github.com/tauri-apps/cef-rs/pull/15/files#diff-2620be2afc249413fa14ee1f678c9c7ab8f0658f44f5c6d49cff57956c716debR27 cc @wravery

It's because of the way that cargo propagates the link flags from the sys crate to its dependencies. Using the [links] attribute in Cargo.toml lets it pass additional key/value pairs to dependencies however far down the dependency chain they are, but it doesn't let you add linker flags to those dependencies.

This way, it's taking the import libs (or the implementation lib in the case of delayimp.lib), and it's statically linking them into the libcef_dll_wrapper.lib static library. They come along with that when cargo statically links libcef_dll_wrapper.lib into any downstream targets. The downstream targets don't need to link anything else, dynamically or statically, to get these import libs linked in.

[wravery]

Actually, that's not quite correct, cargo is associating the link flags with the static library, not statically linking them into it as built by CMake. It's more like adding the link flags/dependencies to a CMake target and getting them added to any downstream consumers of that target along with the output of that target.