On Jul 23, 2008, at 3:20 PM, Shead, Timothy wrote:
On 7/23/08 11:14 AM, "Mike Arthur" <[EMAIL PROTECTED]> wrote:
On Wednesday 23 July 2008 16:06:21 Mike Jackson wrote:
What would probably be nice at this point would be an example OS X
centric project that uses all these ideas with code explanations for
each step.
I think what would be nice is if CMake did this for us! If this is
fairly
standard when packaging on OSX then it would be good if there were
some
integration for this, even if we had to specify the relocations
manually.
That's definitely the long-term intent; in the meantime, an
intermediate
solution would be to do the following:
INSTALL(CODE "EXECUTE_PROCESS(COMMAND install_name_tool -change
/path/to/external.dylib @executable/external.dylib
\${CMAKE_INSTALL_PREFIX}/bin/my_binary)")
... for each combination of binary / external dependency. For a
reasonably-large project this list gets painfully long, but it does
give a
sense of the scope of the problem ;)
One improvement on this approach might be a wrapper for
install_name_tool
that would do regex replacements - many similar install names could be
altered in one-step, or one-at-a-time based on developer preference.
Cheers,
Tim
just to _really_ shine the light on the problem, suppose from the
example above, that you do change that library. You then need to look
at "external.dylib" and see exactly what it depends on and see if any
of those entries need to be changed. For example, in the Qt
Framworkes, QtGui depends on QtCore, so changing the "install_name"
of the QtGui library isn't enough, you need to change the reference
in the QtGui library to reference the QtCore library that is bundled
with the application. So this gets _really_ interesting really quick.
Basically you start with the application, check its dependencies,
change what needs to be changed (System libraries/frameworks do NOT
need to be changed), then move on to each lirbrary, check its
dependencies, change what needs to be changed.. you get the idea.
Just being thorough.
In the solution that I cooked up one of the problems that I had was
that I depended on the external library to be where the path encoded
in the executable said it was. If it had an install_name of
"libexternal.dylib" then my script would not work for that library. I
need a mechanism to be able to "look" for the library somewhere,
maybe I could extract out all the -L arguments to the linker for
that? Dunno. Anyway, it works for my projects currently.
And again, Xcode does not do this for you so it is not surprising
that CMake does not do it.
mike
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
