-
Notifications
You must be signed in to change notification settings - Fork 228
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
build as an installable package and use vcpkg manifest mode to build standalone #1026
base: main
Are you sure you want to change the base?
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. |
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.
@timoore I checked out a clean copy of this branch and ran this on my Windows machine:
And it seems to run ezvcpkg as normal and then also run some other vcpkg process with a different triplet.
(log continues after that, installing more packages) I guess my mistake is that I'm not using the cmake preset that disables ezvcpkg. But ezvcpkg should still be a valid option at this point, right? |
The same happens on macOS, but at least there the triplets are the same ( |
ezvcpkg should be the default if you don't use any of the presets that invoke vcpkg in manifest mode i.e., that load vcpkg.cmake as a toolchain file; I will investigate. I've tried to keep vcpkg manifest mode stuff out of cesium-native's own cmake machinery as much as possible, which means that using it involves passing a bunch of options to cmake or using my handy presets. I would really like cesium-native's build to be agnostic (not care?) about how its dependencies are satisfied. |
After looking at this for "a while," I believe that it's normal that vcpkg.cmake is running again (several times in my experiments). vcpkg abuses the CMake toolchain file, which can be run multiple times during configuration as CMake configures different things. This PR includes new CMake targets etc., which I believe is the cause of more configuration "runs" than in the old code. It is concerning that the triplet used for the subsequent runs of vcpkg is different from the first; I think I know what's up with that and will amend the PR. |
@kring The behavior you were seeing was caused by vcpkg getting invoked in manfest mode even when managed by ezvcpkg. Once vcpkg.cmake is established as the toolchain file, which ezvcpkg does, it will run in manifest mode if it finds vcpkg.json, which is now a part of the source tree... unless told otherwise, which I have now done, politely but firmly. |
This PR has several moving parts:
vcpkg.json
andvcpkg-configuration.json
I'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.