[bug] CMake: No vc runtime babysitting please

[SpaceIm]

Describe the bug
Link errors in executables built with Visual Studio, vc dynamic runtime (default runtime of Visual Studio), and CCTag static.

To Reproduce
Steps to reproduce the behavior:

1. Build static CCTag with Visual Studio
2. Build an executable in another CMake project and link to CCTag static
3. See this error:

CCTag.lib(Types.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in test_package.cpp.obj
   Creating library lib\test_package.lib and object lib\test_package.exp

Expected behavior
No vc runtime babysitting. There is no reason to link to static runtime when CCTag is static (dynamic runtime should be the default one, principle of least surprise). It should be the responsability of users to inject whatever runtime they want while building the lib. Build files should focus on the bare minimum required to build the lib.

Desktop (please complete the following and other pertinent information):

• OS: Windows 10
• CCTag version: 1.0.1

Additional context
I'm packaging CCTag in conan, so I've quickly seen this error since I test all combinations.

Offending code in CMakeLists: https://github.com/alicevision/CCTag/blob/develop/CMakeLists.txt#L44-L66

[Simone Gasparini]

Hi, I came up with that workaround after many painful tries and errors to make it pass on vcpkg.
That code was the only way to make the compilation pass the vcpkg test at the end.
Honestly, I don't know exactly what the problem is and why vcpkg needs that.
If you have a better idea, please do propose a solution (other than removing the lines otherwise it won't work on vcpkg).
Thanks!

[SpaceIm]

I don't know what may happen in vcpkg, but for sure a vcpkg port issue shouldn't lead to introduction of bad practice in your lib. It works just fine in conan by removing these lines: conan-io/conan-center-index#9478

Is there a default behavior in vcpkg like linking to static vc runtime if lib is static or something like this? Maybe ping a vcpkg maintainer to understand what's wrong in CCTag port? I'm pretty sure that vcpkg maintainers wouldn't recommend to hardcode vc runtime in CMakeLists of a lib.

[Simone Gasparini]

I agree with you, we just needed to get the port for various reasons so at some point I went for those changes. But I agree that one should not tamper with the default config.
FYI here is an issue I opened at that time (it was about the other lib, popsift, but the problem was the same)
microsoft/vcpkg#11271

BTW thanks a lot for making the port on conan!
Once it will be merged we should definitely include it in our documentation

[SpaceIm]

BTW thanks a lot for making the port on conan!
Once it will be merged we should definitely include it in our documentation

It has been merged.

• Simple installation:

  conan install cctag/1.0.1@
  

• Simple modern usage in a CMake based project (but probably too much detail to add this in your documentation):

  CMakeLists.txt:

  (...)
  find_package(CCTag REQUIRED CONFIG)
  target_link_libraries(foo PRIVATE CCTag::CCTag)
  target_compile_features(foo PRIVATE cxx_std_14)

  conanfile.txt:

  [requires]
  cctag/1.0.1
  
  [generators]
  CMakeToolchain
  CMakeDeps
  

  Build its project (Release here):

  mkdir build
  cd build
  conan install .. -s build_type=Release
  cmake .. -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Release
  cmake --build . --config Release
  

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.