Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is Being Fixed
This pull request fixes two issues I noticed when I installed the library for development:
Issue 1
A common practice when using
find_package
in CMake is to pin the minimum required version so there are no conflicts between the user code and libraries. This is generally achieved by doingfind_package(<name> <version>)
. This relies on the existence of a<name>configVersion.cmake
file being installed intolib/cmake/<name>
. With the current code, this file is never generated and so never installed, preventing users from requesting a specific version offastgltf
.Issue 2
When building in Windows with Visual Studio, it is common practice to build and install two sets of binaries: one for debug and one for release builds. In user code, CMake will then automatically link the correct binary for the appropriate build. In the current CMake code, there is no way to differentiate between the debug and release builds. This results in the following: if debug is built and installed first, followed by release, the debug library will be overwritten as both debug and release are called
fastgltf.lib
. Using this library in debug builds triggers compiler errors due to mismatched optimisation levels.This can be worked around by manually setting
CMAKE_DEBUG_POSTFIX=d
when building the library, which is error prone and is better set by the library itself.I have verified that both issues are solved with this pull request, and based on past experience with other libraries, doesn't negatively impact other platforms. I think this won't be an issue with
vcpkg
but I've never used it before.