Switching homebrew to CMake build - harcoded paths in binaries

HDF5 Library
1

Hi all!

We are currently trying to switch the homebrew builds to use CMake, since your CMake build offers more features (especially its production of CMake config files for easy inclusion in downstream applications).
However, we are struggling with all the hardcoded paths from the build folders that are present in the build artifacts.

Are we doing something wrong (i.e. forgetting a CMake setting)?
Can we somehow get rid of them?
Will they affect the functionality (i.e. are they used to look up some auxiliary files later at runtime and break programs)?

The corresponding PR is here.
And the issue with some discussion here.

Thank you!

2

To copy some of the relevant information:
I think the CMake call boils down to a simple

cmake -S . -B build
      -DCMAKE_INSTALL_PREFIX=#{install_prefix}
      -DCMAKE_INSTALL_LIBDIR=#{install_libdir}
      -DCMAKE_BUILD_TYPE=Release
      -DCMAKE_FIND_FRAMEWORK=#{find_framework}
      -DCMAKE_VERBOSE_MAKEFILE=ON
      -Wno-dev
      -DBUILD_TESTING=OFF
cmake --build build

and the strings in question can be seen with:

$ strings /opt/homebrew/bin/h5diff | grep /opt
Installation point: /opt/homebrew/Cellar/hdf5/1.14.3
C Compiler: /opt/homebrew/Library/Homebrew/shims/mac/super/clang 15.0.0.15000100
... many many more
3

the last step should be a cpack command, which takes all the build location files and publishes them to the install location. (actually it creates a compressed file that can be uncompressed in the final location).

4

Thank you for the quick answer.
I indeed forgot to list the last command (which comes very late in the script) that does:

cmake --install build

Does your cpack mechanism (I assume you are using a tar.gz package generator or similar) do more than regular cmake install calls and compression? Is cpack therefore preferred over “just” the cmake install target?

5

I think it should provide the same result either way, according to some developers that actually use it.

I use cpack, because it produces a log and locally I can just copy out the root folder (with bin, lib, include, share,cmake folders) wherever I want and can have multiple versions next to each other. Another choice for you might be the presets files. See the CMake documentation. I create a UsersPreset file that I can override the options for my preferred machine settings.

6

Ok thank you for confirming.

I could consider creating a CMakePreset but I think I should first figure out which settings cause the hard coding of strings in the binaries.

To emphasize: building, linking and installation (including relative rpaths for relocation) actually work fine. But we are worried about the hard coded paths that somehow still end up in the binaries.
Or do those strings mean that something actually went wrong?

7

I think I understand what you are asking. Might be a CMake question, but I know from experience on linux that I move the “pacakges” around without any problems. I have noticed build source paths in error stacks. The settings file (which is included in the library as a strings block) will have hardcoded paths, but all that is simply info of how it was built and is not used. The pkconfig files may have build paths, but I believe it is ignored.