Using external dependencies for vcpkg ports - specifically Qt from their installer

[Andne]

I am working through the usage of vcpkg in a project that (eventually) will have a number of ports in a private registry that are consumed by other repositories. However, for now I have a single port in my private registry and a single downstream/top-level project. Both of these depend on Qt 6, along with some other various dependencies. Because I am working mostly in Qt Creator, Qt is generally available and as such I have been relying on its ability to provide the details of the specific Qt installation (I work across both my desktop install and some Boot2Qt installs) to the project build. This was working fine, until I tried to setup the private port and registry to link my projects together.

Once I brought my port project into the top-level project my build no longer works when building for Desktop Qt. Interestingly, it works for Boot2Qt Qt. I'm guessing this is because Desktop Qt relies on CMAKE_PREFIX_PATH in order to find the Qt installation, while Boot2Qt Qt tends to just work because Qt is directly in the sysroot in the provided toolchain and not some other non-standard path. If I modify my portfile.cmake to pass CMAKE_PREFIX_PATH to the configure step as below:

vcpkg_cmake_configure(
  SOURCE_PATH "${SOURCE_PATH}"
  OPTIONS
    -DCMAKE_PREFIX_PATH=/opt/Qt/6.8.4/macos
)

the port builds successfully and I can move on. This implies to me that I simply need to provide CMAKE_PREFIX_PATH in any portfile that expects to have Qt from the installation. That isn't entirely unreasonable, though I wouldn't really call it ideal either. I have a hardcoded path in there because I've been having trouble figuring out what other values are available in this context. Especially which ones will be available regardless of the build environment. Qt Creator does seem to provide QTDIR, so -DCMAKE_PREFIX_PATH=$ENV{QTDIR} also appears to work, but I'm less confident my CI environment or a different IDE would, those rely on my toolchain file to find Qt.

I think some of my confusion is because I don't have a clear picture (or know where/how to get one) for what context different files are parsed in. I know that the ports are built/installed during the CMake configure step, that is part of the toolchain file's responsibility, but what I don't know is what context the portfile.cmake files are read in. Some of the values in them make me think there is another call to CMake from them, but given what variables do appear to be available, I don't think they're loaded in the context of the active project being built either. Is this documented somewhere?

I did find another discussion - #26991 - with a very similar problem, but no specific solution. I also found a discussion - #46102 - that shows one possible solution, but one that appears to rely on other external setup outside of what's consistently available in my environments.

I understand that the initial direction I'm likely to be given here is "use the qt packages in the registry as dependencies". That isn't always possible, and in my case I have customized the build of Qt for our target devices. My product here is an embedded device and so runs a fairly customized Linux distribution, but for development purposes I want the ability to run the application on the developer system as well. Additionally, I am using Commercial Qt, including some Commercial-only modules. While I probably could create the recipes to enable the commercial modules, it still becomes a significant complication and potential build-time issue (though binary caching can potentially help with that last part). I know that I'm definitely wandering off into some interesting territory here, and I don't mind if I have to inject specific workarounds, but so far I haven't been able to determine what the correct form of those workarounds are. This feels like it shouldn't be that far off of a scenario - use vcpkg for some dependencies and rely on system, including stuff outside the sysroot, for other dependencies, especially those that are managed/installed by their own installer - but I so far have not been able to find any hooks that can be clearly used to enable it.