How should a VCPKG based build chain look like?

[Alexander Maret-Huskinson]

Hello,

I looked into the vcpkg tool today and was wondering how the KMyMoney 
build chain should look like, especially when it comes to dependency 
versioning.

Overall vcpkg does not seem to support versioning, but you are supposed 
to checkout the port-versions you are interested in. The build chain 
either needs to know the commit id of each and every dependency or the 
ports have to be added to the KMyMoney codebase. What is the preferred 
approach here? I guess number two is easier to maintain.

In the long term, it will be interesting how this all works out. When 
the main vcpkg tool evolves and gets incompatible to the port versions 
in the KMyMoney repository, then we have to upgrade or lose the 
advantage of community maintained ports. It does not look like vcpkg 
would maintain older port-versions in any way. Or do they?

When it comes to using vcpkg for the AppImg build, there will be a lot 
of challenges. I tried to compile Qt on Ubuntu Xenial today, using 
vcpkg, but the whole build chain is basically incompatible. This is due 
to the versioning problem as well. The Qt dependencies, maintained by 
vcpkg, require build tools which are just not available on Xenial. A 
different cmake version here, a newer phython version there, a different 
version of library xyz and so on.

Maybe this can be fixed by using vcpkg to build the dependencies of the 
build chains of the dependencies (dependency inception anyone?). 
Honestly, I'm quite surprised this works well on Windows and MacOS. My 
experience with vcpkg was pretty messy so far. I hope a lot of these 
problems are due to my ignorance and not real problems.

All the Best
Alex