Manifest builds interfere with each other if one is cross building and the other is not.

[RealLitb]

My repository can be built for target-triplet x64-mingw-dynamic and x64-linux-dynamic. Therefore, I built packages like this, within a Dockerfile. The /tmp/vcpkg-installed is discarded afterwards. The goal is that the commands populate the binary cache directory.

RUN mkdir -p /tmp/vcpkg-installed 
WORKDIR /tmp/vcpkg-installed
ADD vcpkg.json .
RUN $VCPKG_ROOT/vcpkg install --host-triplet=x64-linux-dynamic --triplet=x64-mingw-dynamic
RUN $VCPKG_ROOT/vcpkg install --host-triplet=x64-linux-dynamic --triplet=x64-linux-dynamic

However the second non-cross build interfered with the CMake-files, because when I checkout my repository and build it using the same manifest and for --host-triplet=x64-linux-dynamic --triplet=x64-mingw-dynamic (by defining the VCPKG_TARGET_TRIPLET and VCPKG_HOST_TRIPLET), I get an error in the QtPublicDependencyHelpers.cmake file:

message(FATAL_ERROR
            "To use a cross-compiled Qt, please set the QT_HOST_PATH cache variable to the "
            "location of your host Qt installation.")

My question is: I assume I violated some rule about what can and cannot be done with a single VCPKG checkout. What is the recommended way to go forward? Should I checkout vcpkg twice for this and use distinct worktrees?

[Osyotr]

https://learn.microsoft.com/en-us/vcpkg/commands/common-options#install-root might help

[RealLitb]

I use the manifest mode therefore I think it implicitly uses a different install-root (namely, my cmake build folder which is different for the two cases).

I now think that it's an issue with the binary cache. The problem goes away if I use separate cache directories. The signature of a cached binary does not consider the fact that one is cross building (host != target). But various ports build their packages differently depending on whether cross building is active (and Qt in particular does something with QT_HOST_PATH because certain tools built by Qt need to be invoked on the build host). I think the fact that one is cross building should influence the binary cache's signatures.

[Osyotr]

namely, my cmake build folder which is different for the two cases

You invoke vcpkg manually, so there's no "cmake build folder". Second invocation will remove artifacts from first invocation because of different triplets.

[RealLitb]

The install folder at /tmp isn't used at all. Wen I build with cmake (when running a container that uses the build image), I use the normal manifest mode that installs into a subfolder of the ${CMAKE_BINARY_DIR}. The install to /tmp was merely done to populate a binary cache elsewhere at image build time (which then is used.. but the job of the binary cache is to ensure different artefacts have different signatures). I will gladly accept any help in how to improve the workflow here! But regarding the original problem, that appears to me to be a binary cache bug, unless I'm missing something.

[RealLitb]

My newest Dockerfile does this, to ensure that it populates a different cache and then at CMake time within Docker, I use one of the binary caches depending on the target:

RUN VCPKG_DEFAULT_BINARY_CACHE=${VCPKG_BINARY_CACHE_ROOT}/mingw \
  $VCPKG_ROOT/vcpkg install --host-triplet=x64-linux-dynamic --triplet=x64-mingw-dynamic \
  && rm -rf ${VCPKG_ROOT}/buildtrees ${VCPKG_ROOT}/packages vcpkg_installed
RUN VCPKG_DEFAULT_BINARY_CACHE=${VCPKG_BINARY_CACHE_ROOT}/linux \
  $VCPKG_ROOT/vcpkg install --host-triplet=x64-linux-dynamic --triplet=x64-linux-dynamic \
  && rm -rf ${VCPKG_ROOT}/buildtrees ${VCPKG_ROOT}/packages vcpkg_installed

[dg0yt]

My question is: I assume I violated some rule about what can and cannot be done with a single VCPKG checkout.

As long as you only want to fill the cache, this should work IMO. After the second run, the state should be as if the first run never took place.

This being said, I wouldn't be surprised if there is a subtle cross-build bug in the qt ports.
Or your manifest is pulling in some port in an unexpected way (in particular a script port in the target triplet when it should be in the host triplet).
Can't you provide a minimal manifest to reproduce the issue?