Publish cesium-native to conan and vcpkg

[lilleyse]

Once cesium-native reaches some level of maturity we should consider publishing it to conan and vcpkg like how we publish CesiumJS to npm.

[lilleyse]

First step would be using conan for third party libraries. When not possible we could either find alternative libraries or publish third party libraries on those libraries' behalf.

Here's the initial conan PR: https://github.com/CesiumGS/cesium-native/pull/261

Library	In Conan	Notes
asyncplusplus	:heavy_check_mark:
Catch2	:heavy_check_mark:
cmake-modules	:x:
cpp-httplib	:heavy_check_mark:
CSPRNG	:x:
draco	:heavy_check_mark:
earcut	:heavy_check_mark:
glm	:heavy_check_mark:
GSL	:heavy_check_mark:
modp_b64	:x:	Alternative: https://conan.io/center/base64
PicoSHA2	:x:
rapidjson	:heavy_check_mark:	Use cci.20211112 or newer
s2geometry	:x:	Look at CesiumJS which has no external dependency
spdlog	:heavy_check_mark:
sqlite3	:heavy_check_mark:
stb	:heavy_check_mark:
tinyxml2	:heavy_check_mark:
uriparser	:heavy_check_mark:

[kring]

After having it on the back-burner for awhile, we're starting to look into this again, because an important customer wants to consume cesium-native via Conan. After spending lots of time reading the Conan documentation and looking at various examples, I have more questions than answers. It's crazy complicated. But here are the goals I'm thinking of for cesium-native Conan integration:

1. Each cesium-native library (CesiumGltf, CesiumGeometry, Cesium3DTiles, etc.) is a separate Conan package with its own dependencies on other cesium-native packages and on third-party packages.
2. Conan is used to install dependencies, but is not strictly required. You could install the dependencies another way, put them in your CMake module path, and just run the cesium-native build.
3. Easy development workflow, just hit build after making changes. Ideally using the built-in CMake support for Visual Studio and Visual Studio Code.
4. Minimal repetition, e.g. dependencies stated in only one place.
5. Flexibility to build cesium-native with weird settings, such as "Debug builds use the Release MSVCRT" as required by Unreal Engine. Third party libraries must use these weird settings, too. Which will require building them from source.
6. Try to use the "new" Conan stuff that will still be supported in Conan 2.0 (like CMakeDeps), instead of older stuff that is basically already deprecated (like cmake_find_package_multi). See the note at the top of https://docs.conan.io/en/latest/integrations/build_system/cmake.html
7. Seamlessly support multi-configuration environment like Visual Studio. You shouldn't need to use separate build directories or do a clean build to switch between Debug and Release on Windows.

It's not guaranteed that all of these goals are achievable, particularly in the time we can realistically allot to working on it.

[kring]

From @Samulus:

I would also prioritize ninja compatibility in that list because it's literally 2-10x faster than nmake on Windows (which is perfect for our windows CI) Try using cmake -G "Ninja" -DCMAKE_BUILD_TYPE=Release in the VS developer command prompt. It generates a ninja.build which still uses Microsoft's compiler to compile You can also open a cmake project directly with vs2022 and it seems to default to ninja It's much much much faster but the catch is that ninja is stricter about setting up your dependencies explicitly so some targets might fail until you tweak them

[jherico]

It's worth noting that most of the packages that are marked as missing from Conan here are present in VCPKG:

• picosha2
• modp_b64
• s2geometry

[jherico]

I'll likely work next on a VCPKG PR to get Cesium Native available on VCPKG as a consumable for people who want to use it downstream. I may need to create at least one more PR here to make it more compatible, as when building inside the VCPKG framework, I need to disable all the ezvcpkg logic, since all the dependencies will be built already in the context of VCPKG.