migrate to Conan v2

[kambala-decapitator]

• packages that require custom patches must be built separately with conan build and from the CCI repo
• since Qt 5 requires custom patches, I've also included patches from KDE project. They were generated from a72077a88903fe532f6a749677eb4da4ea99f79f, but a few had to be dropped because Conan can't use them, namely:
  • 0018-Fix-memory-leak
  • 0024-Use-icon-themes-in-QPrintPreviewDialog-if-they-exist
  • 0061-Annotate-QMutex-with-TSAN-annotations
• building LuaJIT for 32-bit platform requires build machine to be able to execute 32-bit code (macOS after 10.14 can't do that for example), see Cross-compiling 32 bit LuaJIT on a 64 bit host LuaJIT/LuaJIT#664

[kambala-decapitator]

failure of cross-building Qt 5 from macOS ARM -> Intel is unexpected. Will check what's wrong, but maybe we'll have to use Intel runner with Xcode 15 to produce Intel deps.

[kambala-decapitator]

finally all deps build correctly.

@IvanSavenko I consider moving all the Conan related things to this repo right in this PR (like described in the Future Improvements), otherwise it's quite inconvenient to work with them.

[IvanSavenko]

If you find this approach more convenient - sure.

Would require copy-pasting conan / CI files from main repo to here, but probably still more convenient.

[kambala-decapitator]

The files will be moved, not copy-pasted. And this repo will be added to vcmi as submodule.

[kambala-decapitator]

automatically created release will look like this (apart from minor cosmetic changes): https://github.com/vcmi/vcmi-dependencies/releases/tag/untagged-5d54e88a0e3d8c424be3

currently ffmpeg started failing for some unobvious reason on Windows (which I can't reproduce even in a separate GhA run in other repo). The intention is that after all builds are green, the draft pre-release becomes non-draft.

Will also adjust to actually create release only when running manually from master branch.

@IvanSavenko Do you have other thoughts / input?

[IvanSavenko]

Will also adjust to actually create release only when running manually from master branch.

Or on PR merge? But works fine for me either way.

currently ffmpeg started failing for some unobvious reason on Windows

That "zlib not found" message? I think we can simply disable zlib support from ffmpeg. From what I see it is only needed to support some rare decoders, which we have disabled anyway. No idea whether this would fix the build though.

Do you have other thoughts / input?

• If Windows-based conan2 fails, perhaps restore vcpkg and keep using it for now, until that problem is resolved? I am OK with removing mingw, since making it work with conan2 will likely need some effort and nobody uses those artifacts at the moment. But still not sure if we need to actually remove vcpkg support that works fine so far and is used by our Windows devs.

• No 32-bit Windows support?

• Why do we need all those Qt patches?

• Looks like dependencies are now packaged as .tgz and not .txz? Fine for me either way though.

[kambala-decapitator]

That "zlib not found" message? I think we can simply disable zlib support from ffmpeg. From what I see it is only needed to support some rare decoders, which we have disabled anyway. No idea whether this would fix the build though.

yes. In my own test repo I can't reproduce for example and can't figure out what's the difference. Especially since it used to work a month ago.

But today I was testing on a virtual windows machine and managed to reproduce random failures with various libraries. The error in all cases was from linker "can't open exe for writing" during internal FFmpeg tests.

I'll try once more in GhA and will upload the conan directory for inspection to see if it's the same reason or not. After that will try disabling zlib.

But still not sure if we need to actually remove vcpkg support that works fine so far and is used by our Windows devs.

what I don't like with vcpkg is amount of project patching to make it work while Conan requires close to zero. (also possible that vcpkg is integrated not quite correctly)

No 32-bit Windows support?

simply didn't add respective matrix dimension, will do

Why do we need all those Qt patches?

KDE patches are recommended for usage (but not required). I decided to include them since Qt requires a few of our custom patches anyway.

Looks like dependencies are now packaged as .tgz and not .txz? Fine for me either way though.

now the archive is created by Conan command and will be restored using its counterpart, and it can do only tgz.

[kambala-decapitator]

ffmpeg+zlib solved, now Qt started failing on 32-bit

[kambala-decapitator]

now Qt started failing on 32-bit

nailed it and opened PR with fix: conan-io/conan-center-index#27449

[Laserlicht]

Can we already add android-x86 and win-arm64 support in first release?

At least android-x86 builds just fine:
https://github.com/Laserlicht/vcmi-dependencies/actions/runs/16399926624

conan-v2...Laserlicht:vcmi-dependencies:conan-v2

[kambala-decapitator]

I think it's ready

[kambala-decapitator]

this workaround needs to be added to win arm64: libsdl-org/SDL#13340

[IvanSavenko]

Perhaps that SDL patch should be added to rest of patches in this PR?

In any case - look OK for me too. What would be the next steps?

• add sdl patch to this PR(?)
• merge this PR
• create release with new packages
• update your conan2 PR in vcmi/vcmi
• test new builds & merge conan2 PR in vcmi/vcmi

?

[kambala-decapitator]

I'll see how to handle that SDL issue, it's possible that simply enabling system C library would fix the error.

Correct for the next steps except that

create release with new packages

Requires crafting new workflow that would create release out of given Actions run, but that is rather easy to do.

[kambala-decapitator]

Will check how to patch opusfile's vs solution that it can be built for arm64

[kambala-decapitator]

opusfile fixed, but just noticed that LuaJIT doesn't build, although this doesn't fail the overall build. Needs patches from LuaJIT/LuaJIT#593

[kambala-decapitator]

let's solve LuaJIT for Windows arm64 later, will open an issue

[IvanSavenko]

Perhaps we can use Lua (non-JIT) on this platform meanwhile?

Would be great to have Lua available on all platforms, but it is not like we're going to rewrite half of logic on Lua so poor performance of non-JIT Lua won't affect gameplay much.

[kambala-decapitator]

good idea! It builds successfully: https://github.com/kambala-decapitator/workflow-test/actions/runs/16783176151/job/47527013007

will adjust CI and recipe to handle different Lua flavors