Using CMake 3.15 & Visual Studio 2019 to build on windows produced a cmake configuration which was unable to be used by clients. Investigating this I was eventually able to determine this was caused by a mismatch in the target properties. Specifically, it was setting the TYPE property to STATIC_LIBRARY even though it was building as a SHARED_LIBRARY.
This in turn was because the if clause on line `if(@BUILD_SHARED_LIBS@)` of this file was evaluating to `if (ON)` which was then not properly evaluated while under the CMake 2.6 policy. Explicitly setting the `CMP0012` policy to NEW fixes the problem.
Instead of using if(ON)/if(OFF) to determine which of the "hardcoded"
add_library(... SHARED ...) or (... STATIC ...) should be used,
specify a new BUILD_LIB_TYPE variable that is set directly to either
SHARED or STATIC and substituted in the `add_library()` statement
when assimpTargets.cmake.in is configured.
This removes a CMP0012 collision with prior `cmake_policy(VERSION 2.6)`
statement and makes the CMP0012 warning not appear in users' projects.
This problem is mentioned in issue #2685.
When built with BUILD_SHARED_LIBS disabled, the exported CMake
targets are modified to reference the static library location.
This also fixes version detection for VS2017 and beyond within
the target import script.
Now the configs follows the standard cmake-package code: see https://cmake.org/cmake/help/v3.12/manual/cmake-packages.7.html
Downstreamer no longer have to manually specify target_include_directories with ${ASSIMP_INCLUDE_DIRS}, target_link_libraries with ${ASSIMP_LIBRARY_DIRS} and so on.
Downstreamer can now use:
find_package(assimp CONFIG REQUIRED)
target_link_libraries(AWESOME_APP PUBLIC assimp::assimp)
and everything should work.
Added assimpTargets.cmake.in
Added assimpTargets-debug.cmake.in
Added assimpTargets-release.cmake.in
Modified CMakeLists.txt
Modified code/CMakeLists.txt - added ALIAS assimp::assimp
Tested on Ubuntu 18.04 and Windows 10
Kim Kulling
Bradley Austin Davis
Robikz
Jack Andersen
dormon