[icu] add host depedency

[autoantwort]

Describe the pull request

• What does your PR fix? Fixes [qt-base] build failure (icu is build for arm with x64-osx triplet) #16424

Same as #16433, but now with host support in vcpkg as base

[JackBoosY]

@Neumann-A Do you have any other questions?

[Neumann-A]

@JackBoosY: all tools should be moved into ${CURRENT_PACKAGES_DIR}/tools/${PORT}/bin if the bin folder is required instead of having an extra for-cross-compile subfolder.

[autoantwort]

@JackBoosY: all tools should be moved into ${CURRENT_PACKAGES_DIR}/tools/${PORT}/bin if the bin folder is required instead of having an extra for-cross-compile subfolder.

Ok, it now don't use the for-cross-compile subfolder anymore.

[JackBoosY]

Shoud we wait for PR #16627?

[autoantwort]

Shoud we wait for PR #16627?

Then we can use ${HOST_TRIPLET} instead of ${_HOST_TRIPLET}

[autoantwort]

I don't think that the x86_windows pipeline failure is caused by the latest commit.

[ras0219-msft]

This looks really great and I'm excited to merge!

I agree with @Neumann-A that it's probably better to use vcpkg_internal_get_cmake_vars() instead of hardcoding -arch x86_64.

[ras0219-msft]

It would probably be better to use vcpkg_copy_tool_dependencies() instead of manually globbing the DLLs. This function may be updated to support .so and .dylib in the future.

[ras0219-msft]

Additionally, we could probably replace the original purge of the bin directory above (line ~340ish) with vcpkg_copy_tools(). Even if vcpkg_copy_tools() isn't applicable, it would be better to move those files to the tools directory instead of deleting and re-copying from the buildtrees.

[autoantwort]

Additionally, we could probably replace the original purge of the bin directory above (line ~340ish) with vcpkg_copy_tools()

The problem with vcpkg_copy_tools() is, that it copies to ${CURRENT_PACKAGES_DIR}/tools/${PORT}, but the files must be copied to ${CURRENT_PACKAGES_DIR}/tools/${PORT}/bin

[Neumann-A]

you could use set(PORT "${PORT}/bin") but you could also add an option like SUBDIR or DESTINATION to vcpkg_copy_tools

[autoantwort]

I have added a DESTINATION parameter to vcpkg_copy_tools

[autoantwort]

The problem with vcpkg_copy_tool_dependencies is, that it does not copy the tool dependencies ...
On my mashine it copies nothing and cmake can't start the applications because of missing dlls

[JackBoosY]

Will rerun the osx pipeline test later.

[JackBoosY]

When building libheif:x64-linux:

CMake Error at gdk-pixbuf/CMakeLists.txt:18 (install):
  install TARGETS given no LIBRARY DESTINATION for module target
  "pixbufloader-heif".

[autoantwort]

When building libheif:x64-linux:

CMake Error at gdk-pixbuf/CMakeLists.txt:18 (install):
  install TARGETS given no LIBRARY DESTINATION for module target
  "pixbufloader-heif".

I think all the ci errors are unrelated to this PR

[JackBoosY]

@autoantwort I've got the failure log, will restart pipeline test now.

[autoantwort]

When building libheif:x64-linux

Maybe #17593 fixes that

[autoantwort]

When building libheif:x64-linux

Maybe #17593 fixes that

Ok seems that a simple rerun solved the problem :)

[Neumann-A]

Ok seems that a simple rerun solved the problem :)

that is because gdk-pixbuf will not be restored in the rerun and so libheif does not pick it up and installs successfully.

[strega-nil-ms]

double documentation! o noes

[autoantwort]

Seems that the DESTINATION option was also added in another PR

[autoantwort]

Most random ci errors were resolved by a rerun, now this PR only depends on #17610

[strega-nil-ms]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[strega-nil-ms]

Thanks @autoantwort :)