Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add exported/installed CMake target #123

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

CJKay
Copy link

@CJKay CJKay commented 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 #118.

@msftclas
Copy link

msftclas commented Apr 1, 2020

CLA assistant check
All CLA requirements met.

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.
@dunhor
Copy link
Member

dunhor commented Apr 7, 2020

It seems like CMake is failing to initialize on the build servers that create and sign the NuGet package. Here's the output:

-- The CXX compiler identification is MSVC 19.16.27038.0
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/WriteBasicConfigVersionFile.cmake:30 (message):
  Unknown keywords given to WRITE_BASIC_CONFIG_VERSION_FILE():
  "ARCH_INDEPENDENT"
Call Stack (most recent call first):
  C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/CMakePackageConfigHelpers.cmake:211 (write_basic_config_version_file)
  CMakeLists.txt:45 (write_basic_package_version_file)

The only thing that stands out is that it seems that these build machines are still using VS 2017 (something out of our control, unfortunately).

Copy link
Member

@ChrisGuzak ChrisGuzak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like goodness but I'm not CMake savvy enough to read this. @dunhor can you check this as I understood you created the cmake and nuget build projects?

@dunhor
Copy link
Member

dunhor commented Aug 9, 2020

There were earlier problems with building the changes on the signing machines (see earlier comment of mine). I haven't checked recently, but I assume those issues still exist. Additionally, #137 from a while ago appears to have addressed the same problem, so there's likely some conflict resolution needed at the very least

@CJKay
Copy link
Author

CJKay commented Aug 11, 2020

Apologies for abandoning this patch on your lap, I've been unable to find the time recently to ensure it's kept up to date.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

No clear directions for integrating WIL into CMake projects
4 participants