Option to link MIGraphX to MSVC Runtime Library statically or dynamically

[apwojcik]

The content of the PR changed from the original submission. Now the PR only adds an option to MIGraphX to enable linking to the MSVC Runtime Library either statically or dynamically. I left the original description below.

Original description:

The change has been migrated from the uai-develop branch.

Windows MIGraphX is still using Protobuf v19. With this PR, we want to switch to Protobuf v30, the same version used by
Linux. However, the Windows environment and differences between Clang make it not a straightforward upgrade.

Using clang-cl requires explicit MSVC runtime library setup for protobuf-generated libraries (and for libraries that link with generated binaries). By default, protobuf sets the MSVC runtime to link statically, while the rest of MIGraphX has the MSVC runtime linked dynamically. We added setting up the MSVC runtime everywhere with this PR, because we will need this in the near future when we switch to linking the MSVC runtime statically for the entire MIGraphX.

Additionally, we do not need to link against SQLite3 if MIGraphX does not depend on the MIOpen.

[pfultz2]

I think you are doing something wrong. The dependencies in requirements.txt build with rbuild using clang-cl, and it doesnt need filter_target_linked_libraries when linking with migraphx.

[pfultz2]

Additionally, we do not need to link against SQLite3 if MIGraphX does not depend on the MIOpen.

I dont think we even use the get_mlir_perf_for_conv anymore, and it probably doesnt even work anymore and should probably be removed. Can you make a seperate PR to remove perfdb.cpp files?

[apwojcik]

I think you are doing something wrong. The dependencies in requirements.txt build with rbuild using clang-cl, and it doesnt need filter_target_linked_libraries when linking with migraphx.

We use clang to compile, and the change is for the clang compiler (not clang-cl). With clang-cl, the MIGraphX compiles with no warnings. We will perform additional testing on binaries built with clang-cl and consider switching the compiler.

[pfultz2]

I think you are doing something wrong. The dependencies in requirements.txt build with rbuild using clang-cl, and it doesnt need filter_target_linked_libraries when linking with migraphx.

We use clang to compile, and the change is for the clang compiler (not clang-cl). With clang-cl, the MIGraphX compiles with no warnings. We will perform additional testing on binaries built with clang-cl and consider switching the compiler.

Either way this change should go into protobuf. MIGraphX shouldn't be monkey patching it.

[apwojcik]

Providing CMAKE_MSVC_RUNTIME_LIBRARY in the command line will not work (in terms of ease of use) for multi-config generators. You do not provide CMAKE_BUILD_TYPE for them when configuring a build because multi-config generators do not use that variable. Instead, you call cmake --build ... --config <build_type>, and then the generator expressions are kicking off to resolve the name of the runtime library. I cannot imagine requiring someone to configure a build to proceed with generator expressions on the command line. Neither library is broken. The authors provided a friendly interface for someone who wishes to configure and build a library easily without deep knowledge of CMake and generator expressions. Please keep in mind that CMAKE_MSVC_RUNTIME_LIBRARY is primarily designed for Visual Studio, which is a multi-config generator.