depends: add zeromq patch to fix mingw CMake file install location #33778

Currently the zeromq CMake files for mingw are installed to x86_64-w64-mingw32/CMake, when they should be in x86_64-w64-mingw32/lib/cmake, so take the patch from upstream that puts them in the right place. Noticed this while looking at other depends changes, that might cleanup / remove dirs.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33778.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

The current path is valid per the CMake docs.

UPD. ... on Windows, but not when cross-compiling.

Concept ACK.

The current path is valid per the CMake docs.

Could you clarify. Reading those docs, <prefix>/(cmake|CMake)/ is only valid on Windows installation trees. Not Unix, which is what is being changed here?

The current path is valid per the CMake docs.

Could you clarify. Reading those docs, <prefix>/(cmake|CMake)/ is only valid on Windows installation trees. Not Unix, which is what is being changed here?

You're right. Already updated my comment.

The current path is valid per the CMake docs.

UPD. ... on Windows, but not when cross-compiling.

On the master branch, find_package(ZeroMQ) succeeds when cross-compiling for Windows. Here is an excerpt from the build log in debug mode:

  Prepending the following roots to each prefix:

  CMAKE_FIND_ROOT_PATH

    /home/hebasto/dev/bitcoin/depends/x86_64-w64-mingw32

  CMAKE_SYSROOT_COMPILE

    none

  CMAKE_SYSROOT_LINK

    none

  CMAKE_SYSROOT

    none

  find_package considered the following locations for ZeroMQ's Config module:

    /home/hebasto/dev/bitcoin/depends/x86_64-w64-mingw32/ZeroMQConfig.cmake
    /home/hebasto/dev/bitcoin/depends/x86_64-w64-mingw32/zeromq-config.cmake
    /home/hebasto/dev/bitcoin/depends/x86_64-w64-mingw32/CMake/ZeroMQConfig.cmake

  The file was found at

    /home/hebasto/dev/bitcoin/depends/x86_64-w64-mingw32/CMake/ZeroMQConfig.cmake

@purpleKarrot

Could you please clarify (1) whether this CMake behaviour is expected and (2) whether the current path is valid?

The current path is valid per the CMake docs.

UPD. ... on Windows, but not when cross-compiling.

When taking cross-compiling into account, there are not two, but three scenarios how mingw can be used:

1. Building on Windows
2. Building on Linux, but packaging for Windows
3. Building on and packaging for Linux

CMake searches for packages in different paths depending on the build host platform. The variable WIN32 describes the build target platform. It is not possible to deduce the packaging target platform from either the build host platform nor the build target platform.

Without the patch, scenarios 1+2 are supported by default. With the patch, that was also applied upstream (https://github.com/zeromq/libzmq/commit/7a7bfa10e6b0e99210ed9397369b59f9e69cef8e), scenarios 1+3 are supported by default. Whether 1+3 are actually more appropriate as a default than 1+2 is debatable. I would have rejected that change upstream.

But whatever the default, the packager can override it by setting ZEROMQ_CMAKECONFIG_INSTALL_DIR explicitly, so all three scenarios are actually supported both with and without the patch.

This is also the simplest approach for us. Instead of adding a patch, set ZEROMQ_CMAKECONFIG_INSTALL_DIR:

 define $(package)_config_cmds
-   $($(package)_cmake) -S .. -B .
+   $($(package)_cmake) -S .. -B . -DZEROMQ_CMAKECONFIG_INSTALL_DIR:STRING=share/ZeroMQ
 endef

<!--9cd9c72976c961c55c7acef8f6ba82cd-->

Guix builds (on x86_64) [untrusted test-only build, possibly unsafe, not for production use]

I wont bother changing this for now (also don't want to add to /share given that bundles content we are currently pruning). Maybe we can also convince upstream to rechange their approach.