kicad-developers team mailing list archive

[Simon Wells <swel024@xxxxxxxxx>]

As a couple of OSX devs have run into this issue i am going to
document it here so that future people are able to find it...

The issue occurs during the "make install" phase of kicad on osx
(hence this only affects devs not users) and will mention something
about not being able to find

@loader_path/libboost_<module>.dylib
i have commonly seen this with libboost_chrono-mt.dylib

This is due to how FindBoost.cmake is configured in that every new
version of boost requires manual intervention to make it work again
due to

function(_Boost_COMPONENT_DEPENDENCIES component _ret)

elseif(NOT Boost_VERSION VERSION_LESS 106100 AND Boost_VERSION
VERSION_LESS 106200)
elseif(NOT Boost_VERSION VERSION_LESS 106200 AND Boost_VERSION
VERSION_LESS 106300)
etc.

The most recent version also has the AND and so it will not work for
any future versions without an updated FindBoost.cmake script. As the
release cycles for boost and cmake are not synced this typically
leaves at least a month between boost release and the next cmake
release fixing the FindBoost.cmake file

As such there are a couple of ways to solve this issue.

1. Downgrade boost to a version that is older than the cmake release
you are running (on brew this is a case of using $ brew switch boost
<next older version you have installed (if you just updated
discoverable through brew info)>)
2. Check cmake git master to see if the file has been updated and copy
the changes into your system FindBoost.cmake (on brew
/usr/local/opt/cmake/share/cmake/Modules/FindBoost.cmake)
3. Remove the AND in the FINAL elseif statement (not really
recommended as may not be correct for the new version of boost)
4. install and use cmake HEAD in boost (there may still be a couple of
day delay in the updated script but not nearly as bad as it is now)

I have sent this updated information to the cmake mailing list (as i
was unable to figure out the cause when i last experienced the issue
back in jan so hopefully we may see some changes in getprereqs/bundle
utilities in the future which may reduce the dependency on this issue)
However that will be unlikely until at least cmake 3.8 so don't expect
it to be the required cmake version any time soon.

Simon