build as an installable package and use vcpkg manifest mode to build standalone #1026
Conversation
This is basically the addition of the vcpkg.json manifest and vcpkg-configuration.json, which are both pretty minimal. In practice, projects will probably copy those and add overlays.
Should be a no-op at this point, but will be required when we make Cesium Native installable.
The intent is for public target sources to be compiled into consumers of a target, but that is a no-op for header files. Including the public headers, which have paths pointing inside the project, causes an error when generating an export set.
This create the CMake files that create targets in an imported package.
Add a find module for zlib-ng, which can be installed and included by a config package. Other find modules may be necessary too.
VCPKG_MANIFEST_MODE isn't available before project() is called, so define a new variable CESIUM_USE_EZVCPKG to control the early loading of ezvcpkg.
Individual integrations can add their own overlay if they need it.
Also, try to make sure that vcpkg actually uses the desired triplet.
|
Looks like this causes the following issue in cesium-unreal: Not sure why this would have broken here - the cesium-unreal/extern CMakeLists.txt is unchanged here and I don't see why the |
|
Thanks for being brave enough to test this with Cesium Unreal! What generator was used to build cesium-native? |
|
The problem is in the new cesium-native/CMakeLists.txt, which defines exports to install. The install(EXPORT...) command doesn't support generator expressions in its destination argument... which makes a certain amount of sense, even if it's inconsistent. The export files won't be used in the Unreal build, but I'll change the command to use a more suitable variable. |
In the Cesium for Unreal build, CMAKE_INSTALL_LIBDIR contains
a generator expression, which the install(EXPORT ...) command doesn't
process correctly. So, install the configuration files such as
"cesium-nativeTargets.cmake" in
${CMAKE_INSTALL_DATADIR}/cesium-native/cmake, which is a perfectly
fine location.
These files aren't used by the Cesium Unreal build anyway.
|
I've started to look at how to use this in cesium-unreal and have hit a bit of a sticking point with specifying the MSVC toolset version to build those parts of cesium-unreal/extern that wouldn't be vcpkg port overlays. Maybe this isn't a real issue, because I think the GitHub build action would work the same. It's really only a problem for developers who have multiple toolsets installed. It is possible to set the toolset version through CMakePresets.json, and on the command line, but otherwise it is really obscure. Do you think this is worth worrying about? Just to be clear, this isn't a new problem that comes with vcpkg manifest mode. |
|
I've been trying to package this (Homebrew for now, later Gentoo) so I can use it as a dependency for vsgCs which I want to use in something I'm working on, however right now it seems pretty much impossible to do so without significantly changing the build files. This patchset looks like it could improve that, however with this it fails to even configure in the Homebrew build environment:
https://gist.github.com/2xsaiko/9d2bc0691529d2599e2d43d8cf7e8ec5 Strangely enough, this error doesn't occur when running it outside of the Homebrew package. Any ideas? |
The In your build that is crashing, it looks like the ezvcpkg code is getting confused by the vcpkg.json mainifest file and is then going into manifset mode. This is interesting as I would like to keep ezvcpkg working for a while, but for experimenting with this PR you probably want to specify CESIUM_USE_EZVCPKG=OFF. |
|
Gave this a shot using vsgCs and I'm getting this build error when vcpkg tries to install cesium-native: I've no idea what might be causing this to happen when vcpkg tries building it, since cesium-native builds fine on its own in the same environment. The only thing I can think is that this build is using |
|
For what its worth, I have the exact same issue as above. Is there a workaround or fix available? Thanks. |
|
I'm taking a look at this, but I'm curious: do @azrogers or @HellfireATGM have more than one version of the Visual Studio toolset installed? It can be quite tricky to insure that vcpkg packages and the main project all use the same version. |
|
I can't reproduce this with the latest vsgCs sources. |
|
Sorry, my bad. Didn't realize there was a config for windows. I did the cmake with this preset: All good now. Thanks. |
|
Sorry @timoore I'm not really comfortable merging this before next week's release. I haven't reviewed it in depth, but one problem I see is that the CI build times are drastically increased. I think the caching isn't working anymore. Let's aim to get it in as soon after next week's release as we can, and we can even tag a mid-cycle native release if it's helpful. |
The cache management page for cesium-native says: This PR creates new caches for the VCPKG builds that are probably no smaller than the caches for ezvcpkg. I don't think that the caches for this PR are being kept around (or are even being created), and I wouldn't be surprised if caching for all the builds is being affected. |
|
I've tried to set up vcpkg caching with S3, but I'm getting a spew of errors like: so I clearly don't know what I'm doing. |
We were picking up the debug version in release builds, which causes -- at the least -- an annoying message.
... and fix indentation.
This PR has several moving parts:
vcpkg.jsonandvcpkg-configuration.jsonI'm using this branch to build vsgCs using cesium-native as a vcpkg overlay port. That usage needs to be documented here too. Also, while I've tried to preserve the old behavior using exvcpkg, I haven't tested this yet with Cesium for Unreal and other integrations in the classic style of using cesium-native as a CMake subdirectory.