Re: [cmake-developers] fixup_bundle with @loader_path
Hello, I think i have finally figured out whats causing the issue FindBoost.cmake explicitly lists the dependencies for every version, and therefore provides this information to cmake and getprereqs function(_Boost_COMPONENT_DEPENDENCIES component _ret) As each new version of boost is released the dependency information has to be added manually to FindBoost.cmake. elseif(NOT Boost_VERSION VERSION_LESS 106200 AND Boost_VERSION VERSION_LESS 106300) is the newest line which is in trunk but has yet to be released As such if one has installed a new boost version and not yet got an updated cmake version then it will not be providing the right information as such it seems the getprereqs will then go inspecting the installed boost libraries eg. /usr/local/opt/boost/lib/libboost_context-mt.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/libboost_chrono-mt.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/libboost_thread-mt.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0) as such will not understand it and will fail at trying to copy @loader_path/libboost_chrono-mt.dylib This explains why the bug has mysteriously disappeared on me a couple of times and why it never fails to make a reappearance thanks Simon On Fri, Jan 15, 2016 at 7:26 AM,wrote: > > - On Jan 14, 2016, at 6:48 AM, Brad King brad.k...@kitware.com wrote: > >> On 01/13/2016 01:38 AM, Simon Wells wrote: >>> it kept saying that @loader_path/libboost_chrono-mt.dylib was not found >> >> It looks like this was now reported here with a patch: >> >> https://cmake.org/Bug/view.php?id=15918 >> >> We already handle @executable_path, so @loader_path should be handled in >> a similar way but we need to make sure enough information is passed to >> know the loader path. >> > > As far as I know, the information needed is already available, so my initial > guess is that we don't need any significant re-engineering. > > Simon, > Would you happen to have a simple example showing the problem without boost, > that would be easy to replicate? That could become the basis for a test. > > Clint -- 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
Re: [cmake-developers] fixup_bundle with @loader_path
On 01/13/2016 01:38 AM, Simon Wells wrote: > it kept saying that @loader_path/libboost_chrono-mt.dylib was not found It looks like this was now reported here with a patch: https://cmake.org/Bug/view.php?id=15918 We already handle @executable_path, so @loader_path should be handled in a similar way but we need to make sure enough information is passed to know the loader path. Clinton? Thanks, -Brad -- 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
Re: [cmake-developers] fixup_bundle with @loader_path
- On Jan 14, 2016, at 6:48 AM, Brad King brad.k...@kitware.com wrote: > On 01/13/2016 01:38 AM, Simon Wells wrote: >> it kept saying that @loader_path/libboost_chrono-mt.dylib was not found > > It looks like this was now reported here with a patch: > > https://cmake.org/Bug/view.php?id=15918 > > We already handle @executable_path, so @loader_path should be handled in > a similar way but we need to make sure enough information is passed to > know the loader path. > As far as I know, the information needed is already available, so my initial guess is that we don't need any significant re-engineering. Simon, Would you happen to have a simple example showing the problem without boost, that would be easy to replicate? That could become the basis for a test. Clint -- 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
[cmake-developers] fixup_bundle with @loader_path
I currently have boost installed through brew of which kicad uses libboost_context-mt.dylib this library then depends on libboost_chrono-mt.dylib the otool -L for libboost_context-mt.dylib for chrono is @loader_path/libboost_chrono-mt.dylib After having numerous issues with trying to get this working as it kept saying that @loader_path/libboost_chrono-mt.dylib was not found, I was doing some testing with the help of Lewoco and found a few things BundleUtilities.cmake requests a list of prerequisites using get_prerequisites and theoretically this should return the full path that was found in gp_resolve_items (from get_prerequisites) however due to how get_prerequisites functions the full path is not being added to the prerequisites_var which is "returned". I believe this has to do with gp_append_unique(${prerequisites_var} "${item}") as that would add the @loader_path version of the path rather than the resolved path. And when its recursive, and so the full path is then used in a recursive call to get_prerequisites the function doesn't allow it to add itself to the list. unfortunately i don't understand enough about how the function actually works to know the best way to patch this but i assume it would be better if only resolved items were added to the prerequisite_vars as otherwise its possible they would not have enough information to be resolved later If i am missing something or have made a mistake somewhere please let me know thanks Simon -- 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