No clear directions for integrating WIL into CMake projects #118
Labels
feature-request
New feature or request
Comments
|
Correct. The use of CMake here is predominantly for building the tests. Feel free to issue a PR if the scenario is important to you. |
CJKay
added a commit
to CJKay/wil
that referenced
this issue
Apr 1, 2020
This commit adds the `WIL` CMake interface library, which allows the project to be exported and installed for consumption by other CMake projects in the standard fashion. The logic to create the NuGet package has been replaced with the built-in CPack NuGet support introduced with CMake 3.13, which automatically packages any files and directories installed by the target. Note that the original NuGet specification file used the new license style, whereas CPack still generates a NuGet specification with the deprecated style. This will hopefully be resolved by future versions of CPack. Resolves microsoft#118.
CJKay
added a commit
to CJKay/wil
that referenced
this issue
Apr 1, 2020
This commit adds the `WIL` CMake interface library, which allows the project to be exported and installed for consumption by other CMake projects in the standard fashion. The logic to create the NuGet package has been replaced with the built-in CPack NuGet support introduced with CMake 3.13, which automatically packages any files and directories installed by the target. This replaces the `make_wil_nupkg` custom target with the standard CPack `package` target, which builds the package with all the configured package generators (for now that's just NuGet). Note that the original NuGet specification file used the new license style, whereas CPack still generates a NuGet specification with the deprecated style. This will hopefully be resolved by future versions of CPack. Resolves microsoft#118.
CJKay
added a commit
to CJKay/wil
that referenced
this issue
Apr 1, 2020
This commit adds the `WIL` CMake interface library, which allows the project to be exported and installed for consumption by other CMake projects in the standard fashion. The logic to create the NuGet package has been replaced with the built-in CPack NuGet support introduced with CMake 3.13, which automatically packages any files and directories installed by the target. This replaces the `make_wil_nupkg` custom target with the standard CPack `package` target, which builds the package with all the configured package generators (for now that's just NuGet). Note that the original NuGet specification file used the new license style, whereas CPack still generates a NuGet specification with the deprecated style. This will hopefully be resolved by future versions of CPack. Resolves microsoft#118.
|
Allow me to second this - I had some trouble integrating WIL in Dolphin's cmake: dolphin-emu/dolphin#8427 |
|
You might be interested in #123 |
CJKay
added a commit
to CJKay/wil
that referenced
this issue
Apr 5, 2020
This commit adds the `WIL` CMake interface library, which allows the project to be exported and installed for consumption by other CMake projects in the standard fashion. The logic to create the NuGet package has been replaced with the built-in CPack NuGet support introduced with CMake 3.13, which automatically packages any files and directories installed by the target. This replaces the `make_wil_nupkg` custom target with the standard CPack `package` target, which builds the package with all the configured package generators (for now that's just NuGet). Note that the original NuGet specification file used the new license style, whereas CPack still generates a NuGet specification with the deprecated style. This will hopefully be resolved by future versions of CPack. Resolves microsoft#118.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Generally speaking, CMake libraries that are intended for use elsewhere will install an exports file - usually in
${INSTALL_DIR}/cmake/<project>Config.cmake- in order to allow third party CMake projects to locate the library withfind_package(<project>). WIL does not appear to provide this CMake configuration file, and so it is unclear how the user is expected to integrate it into other CMake projects, and means that CMake projects that would otherwise usefind_package()to pull in their dependencies now need to provide custom logic for WIL.Now, it appears to me that CMake is not strictly used to package the library itself, but rather to do the packaging and testing tasks. I think the library would be well served with an exported interface library target which we could then pull in much more easily.
The text was updated successfully, but these errors were encountered: