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