Set install_name for plug-ins on macOS

[moubctez]

Describe the bug indi_Nearest_MathPlugin and indi_SVD_MathPlugin require a proper install name as these are not installed directly in PREFIX/lib.

To Reproduce

1. Compile version 2.0.9 with CMAKE_INSTALL_NAME_DIR=@PREFIX@/lib (where @PREFIX@ is an arbitrary path)
2. Check the plug-ins with otool -L
3. See that library names are not set properly.

Expected behaviour Install_name is set for plug-ins sub-directory.

Desktop (please complete the following information):

• OS: macOS
• Version 14.6

Fix

--- libs/alignment/CMakeLists.txt.orig  2024-08-05 10:54:29.125435547 +0000
+++ libs/alignment/CMakeLists.txt
@@ -145,6 +145,9 @@ set(NearestMathPlugin_SRCS
 )

 add_library(indi_Nearest_MathPlugin SHARED ${NearestMathPlugin_SRCS})
+IF(APPLE)
+    set_property(TARGET indi_Nearest_MathPlugin PROPERTY INSTALL_NAME_DIR ${INDI_MATH_PLUGINS_DIRECTORY})
+ENDIF()
 target_include_directories(indi_Nearest_MathPlugin
     PRIVATE
         ${libindi_SOURCE_DIR}/libs/indicore
@@ -168,6 +171,9 @@ set(SVDMathPlugin_SRCS

 add_library(indi_SVD_MathPlugin SHARED ${SVDMathPlugin_SRCS})
 set_property(TARGET indi_SVD_MathPlugin APPEND PROPERTY COMPILE_DEFINITIONS SVD_TRANSFORM_MATRIX)
+IF(APPLE)
+    set_property(TARGET indi_SVD_MathPlugin PROPERTY INSTALL_NAME_DIR ${INDI_MATH_PLUGINS_DIRECTORY})
+ENDIF()
 target_link_libraries(indi_SVD_MathPlugin
     indidriver
     $<$<PLATFORM_ID:CYGWIN>:AlignmentDriver>

[rlancaste]

I tested your change and it does change the install name to an absolute path to the folder it is installed in. But without your change it is an rpath install name (@rpath/libindi_Nearest_MathPlugin.dylib).

I have preferred to use rpaths rather than absolute folder paths for the install names for the last few years. Is there a reason to make it an absolute path again? For background, a few years ago we had some really bad issues with building KStars and INDI where prebuilt libraries had crazy install names since they were built on different systems. They did not work with those absolute path names since they were incorrect when the library was moved to a different folder or on a different person's computer. One very useful solution was using the rpath based install names and then making sure the correct rpath has been added to the executable calling on or building based on the library.

This made it much more portable for packaging, distribution, linking, and testing purposes since the install name of the library could remain the same and it just required a simple command to update the linking to the new folder structure. This worked whether it was in the craft structure, on a personal machine, on another persons personal machine, or in the KStars App bundle.

This issue was not really related to these particular libraries since these libraries are actually built on the same machine that would be doing the distribution, but it is the reason I have preferred linking with rpaths instead of absolute paths. Because the solution has worked so well, I have just preferred using rpaths.

Is there a reason to use the absolute path here?

[knro]

@moubctez Any comments on @rlancaste comment above?

[github-actions[bot]]

This issue has been inactive for 60 days and is being marked as stale.

[github-actions[bot]]

This issue has been closed due to inactivity.