CMake: set BUILD_WITH_INSTALL_NAME_DIR for macOS

[markmentovai]

CMake can either build shared libraries with a temporary install_name at build time, resetting it to the final name at install time (BUILD_WITH_INSTALL_NAME_DIR=NO, the default), or it can build them with the final name at build time (BUILD_WITH_INSTALL_NAME_DIR=YES).

GDAL plugins link against libgdal as part of the build process, and if BUILD_WITH_INSTALL_NAME_DIR=NO, these plugins may be linked using an incorrect path to libgdal, taken from libgdal’s install_name. Those paths are not rewritten at install time, which can make it difficult to properly use GDAL plugins built in this way. For example, with GDAL built with a CMAKE_INSTALL_NAME_DIR set (as a downstream build may do), and PDF built as a plugin, gdal info on a PDF may fail with an error such as:

ERROR 1: dlopen(…/lib/gdalplugins/gdal_PDF.dylib, 0x0001): Library not loaded: @rpath/libgdal.39.dylib
  Referenced from: <…> …/lib/gdalplugins/gdal_PDF.dylib
  Reason: no LC_RPATH's found

Setting BUILD_WITH_INSTALL_NAME_DIR=YES overcomes this problem. This change should be noncontroversial, as the default GDAL build, without a CMAKE_INSTALL_NAME_DIR set, will use @rpath as the install_name_dir in both the build and installed trees, regardless of the setting of BUILD_WITH_INSTALL_NAME_DIR.

What does this PR do?

What are related issues/pull requests?

AI tool usage

• AI (Y-a-t-il-un-Copilot-dans-l'avion, Chat-j'ai-pété, Jean-Claude Dusse or something similar) supported my development of this PR. See our policy about AI tool use. Use of AI tools must be indicated.

Tasklist

• Make sure code is correctly formatted (cf pre-commit configuration)
• Add test case(s)
• Add documentation
• Updated Python API documentation (swig/include/python/docs/)
• Review
• Adjust for comments
• All CI builds and checks have passed
• ADD YOUR TASKS HERE

Environment

Provide environment details, if relevant:

• OS: macOS 26.5 25F71
• Compiler: Xcode 26.5 17F42, Apple clang version 21.0.0 (clang-2100.1.1.101)

[rouault]

What is the effect of this change for GDAL developers building with plugins, but not installing GDAL, and wanting to use the non-installed build ?

[markmentovai]

#14660 (comment):

What is the effect of this change for GDAL developers building with plugins, but not installing GDAL, and wanting to use the non-installed build ?

If they are not currently setting CMAKE_INSTALL_NAME_DIR, there is no impact. The install_names will all have @rpath-based paths as they do now, like @rpath/libgdal.39.dylib.

In addition, if these developers are setting CMAKE_INSTALL_NAME_DIR but are additionally setting DYLD_LIBRARY_PATH in the environment, there is no impact. That environment variable supersedes the path component of any install_name.