On Tuesday, September 16, 2014 08:48:31 PM Adam Strzelecki wrote:
> > Instead, can you extract rpaths for a binary in BundleUtilities and pass
> > that into gp_resolve_item via the existing dirs argument?
>
> Okay, fixed this in the new 3/6 + 4/6 patches, attached to previous patch
> post.
>
> FYI I cannot use existing dirs arguments because other replacements search
> paths shouldn't look into rpath, only @rpath replacements.
Sure, but the caller can also check for @rpath and in that case add the rpaths
to the existing dirs argument.
Yes, there are other find_file() searches in there, that could potentially mess
up if the actual filename had "@rpath" in it.
But I would also argue that the general fallback
find_file(ri "${item}" ${exepath} ${dirs} /usr/lib)
can undesirably be affected by other variables such as CMAKE_INCLUDE_PATH.
>
> So instead I added extra optional rpaths argument to all GetPrerequisites
> functions that somewhere call gp_resolve_item so need to carry rpaths.
>
> WDYT?
>
> --Adam
Can you explain the "exepath" to "executable" change in the function
signatures? I have the impression you changed the signature of several
functions to accept
"/path/to/executable"
instead of
"/path/to/"
No? These functions are called by other codes and we can't just change the
meaning of the arguments.
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
