We use cesium-native and I’m wondering why you guys decided to use ezvcpkg for dependencies (my team is considering different options for our dependencies). Is it just to speed up rebuilds, since it puts packages outside the build directory? ezvcpkg doesn’t seem to be actively maintained, with the last update 2 years ago, and the author not being very active on github in the past year…
@trifonov-borislav There’s a very simple explanation for this: if you’ll look through the author of ezvcpkg’s activity on GitHub, you might notice some activity in Cesium Native - particularly, as the creator of the PR that added vcpkg support. The #1 reason we used vcpkg is that the team had other things we needed to be working on, and someone from the community was helpful and patient enough to do the work of replacing our previous submodule mess with evcpkg, and we went with that solution. That’s not to say ezvcpkg doesn’t have its benefits, of course: it’s easier for us to cache our dependencies on CI, and it lets us grab our vcpkg dependencies without needing vcpkg to be installed on the system, so none of our development instructions or CI configurations needed to change very much.
We would like to eventually switch over to vcpkg manifest mode. Our goal is to eventually get Cesium Native published onto a vcpkg registry so users can install it in their projects like any other vcpkg package. In fact, @Timothy_Moore has been hard at work on this over the past few months, and seems close to a solution last I heard. So if you’re looking for an alternative to ezvcpkg, I’d suggest giving that branch a try and reporting any bugs you find in the comments of the PR to help us get it finished up!
We are already using vcpkg in manifest mode, so I’m wondering how you plan to deal with the issue of caching dependencies on CI when you switch to manifest mode (in our case, would also be great to cache across docker container builds). I see that vcpkg has the VCPKG_BINARY_SOURCES option but our team hasn’t tried it yet
Tim could give more information since he’s just gone through the pain of figuring it out, but I believe it’s using VCPKG_BINARY_SOURCES with the x-aws configuration option to cache things in an S3 bucket. You can see his in-progress work in the GitHub build.yml in the PR I linked.
1 Like
Looks great, though ideally for local builds it shouldn’t re-download from S3 every rebuild…
Looks great, though ideally for local builds it shouldn’t re-download from S3 every rebuild…
We’re only using VCPKG_BINARY_SOURCES in CI on github, and we use S3 there because the GitHub actions cache isn’t big enough for all our builds. Locally you can use whatever binary caching scheme you like; I don’t use any apart from the default vcpkg filesystem-based caching.