Use vcpkg for providing dependencies.

[DorianBDev]

Description

Use vcpkg for providing third party dependencies. This is the continuation of @agatti work on #36.

Affected area(s)

• Core
• GUI
• Tests

Changes type

• Bug fix
• Migration
• New feature
• Feature rework

[DorianBDev]

Some notes on vcpkg usage:

• Pinning dependencies' versions is a pain.
• Cache is huge (~18gb on my machine, mainly because of Qt).
• Porting the "deploy" CIs might be difficult.
• Porting the Windows CIs might be difficult.
• Initial compile time exploded, due to dependency building (maybe a good x3).
• Qt through vcpkg implies having a bunch of dependencies pre-installed (~14 for debian-based distros, since Qt is built from source now).

[DorianBDev]

vcpkg and github-actions have an issue with Qt and CI caching... Which force to rebuild Qt every time the CI is run. A PR is available here microsoft/vcpkg-tool#1043 but not merged. This doubles the CI execution times.

[DorianBDev]

After further exploration of VCPKG and Windows :

• Qt6 has removed Angle support, which was very useful under Windows as a fallback solution when no OpenGL runtime is found. The alternative is to use the mesa llvmpipe software renderer, which we have to provide via a dynamic library with vcpkg... Which requires to build LLVM locally. A no go for me.
• Since we use QtInstallerFramework as installer system for Degate, and since VCPKG doesn't have a port for it, we'll still have to use Qt dependency in the deploy CIs.
• Having to build Qt locally to work on Degate (or even in the CIs) is an issue for disk space and initial building time.

About all this, I think I'll try to create a hybrid system in which CMakeLists.txt will try to use the local version of a library (for example, provided by the system's package manager), or, if nothing has been found, it will use VCPKG. The deploy CIs/system will then only work if Qt6, QInstallerFramework and mesa llvmpipe dll (Windows only) are available locally (not via VCPKG).

Edit: windeployqt.exe is also so broken when provided by VCPKG... It create a non-working deploy folder, and copy useless things, bloating everything.

[Pospelove]

Cache is huge (~18gb on my machine, mainly because of Qt).

There is an option for cleaning the buildtrees and downloads folder of vcpkg after build:
See https://github.com/skyrim-multiplayer/skymp/blob/main/CMakeLists.txt#L25

Regards,
Yet Another Person Who Suffers From GHA Cache Limits

[DorianBDev]

There is an option for cleaning the buildtrees and downloads folder of vcpkg after build: See https://github.com/skyrim-multiplayer/skymp/blob/main/CMakeLists.txt#L25

Thanks for the advice!

Regards, Yet Another Person Who Suffers From GHA Cache Limits

I feel this...

[DorianBDev]

After further exploration of VCPKG and Windows :

* Qt6 has removed Angle support, which was very useful under Windows as a fallback solution when no OpenGL runtime is found. The alternative is to use the mesa llvmpipe software renderer, which we have to provide via a dynamic library with vcpkg... Which requires to build LLVM locally. A no go for me.

* Since we use QtInstallerFramework as installer system for Degate, and since VCPKG doesn't have a port for it, we'll still have to use Qt dependency in the deploy CIs.

* Having to build Qt locally to work on Degate (or even in the CIs) is an issue for disk space and initial building time.

About all this, I think I'll try to create a hybrid system in which CMakeLists.txt will try to use the local version of a library (for example, provided by the system's package manager), or, if nothing has been found, it will use VCPKG. The deploy CIs/system will then only work if Qt6, QInstallerFramework and mesa llvmpipe dll (Windows only) are available locally (not via VCPKG).

Edit: windeployqt.exe is also so broken when provided by VCPKG... It create a non-working deploy folder, and copy useless things, bloating everything.

Everything should be working now. By default Qt use the local version on the machine, and if using a specific vcpkg-qt (add -DVCPKG_QT option to cmake) feature it will build Qt from source using vcpkg. I just have to do some more testing and update the README, but everything should be fine for a merge.