[CMake] INSTALL_NAME_DIR on MacOSX
Alan W. Irwin
irwin at beluga.phys.uvic.ca
Wed Oct 24 17:25:05 EDT 2007
On 2007-10-24 13:54-0600 James Bigler wrote:
>> Here is what works for us:
>>
>> if(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
>> # No rpath on Darwin. Setting it will only cause trouble.
>> else(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
>> option(USE_RPATH "Use -rpath when linking libraries, executables" ON)
>> endif(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
>>
>> if(USE_RPATH)
>> set_target_properties(
>> plplot${LIB_TAG}
>> PROPERTIES
>> SOVERSION ${plplot_SOVERSION}
>> VERSION ${plplot_VERSION}
>> INSTALL_RPATH "${LIB_INSTALL_RPATH}"
>> INSTALL_NAME_DIR "${LIB_DIR}"
>> )
>> else(USE_RPATH)
>> set_target_properties(
>> plplot${LIB_TAG}
>> PROPERTIES
>> SOVERSION ${plplot_SOVERSION}
>> VERSION ${plplot_VERSION}
>> INSTALL_NAME_DIR "${LIB_DIR}"
>> )
>> endif(USE_RPATH)
>>
>> For completeness I left in the SOVERSION and VERSION properties we set for
>> the PLplot principal library, but the only difference between the two
>> alternatives is INSTALL_RPATH "${LIB_INSTALL_RPATH}"
>>
> ...
>> I hear from PLplot OS X users that the above CMake logic also works well
>> on
>> that platform both for the build tree (where I assume CMake automatically
>> does not use rpath for the Darwin case) and install tree (where because
>> of the above logic CMake does not use rpath for the Darwin case).
>
> This would work if one had the exact path the library would be in while
> compiling.
Sorry, I should have stated that the CMake variable LIB_DIR above is
the configured install location for the libraries.
> Unfortunately, there needs a flexible mechanism to install the
> binaries in different places.
Well, the above is flexible in the sense that the user has complete control
over the install location for the libraries at cmake time. I haven't tried
multiple install locations for the same build tree, but I suspect those
would not work and you would need different build trees (or complete removal
of the original build tree) for different install locations. Thus, this
mechanism might not be as flexible as you desire. OTOH, if you have code
that depends on the install location (e.g., PLplot has some installed map
files and font files it needs access to), the normal/obvious thing to do is
to configure that code with CMake. So the above mechanism for choosing
install locations is all that is available to us in the PLplot case, and you
might have similar constraints.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
More information about the CMake
mailing list