[CMake] avoiding finding system libraries (motivation is superbuilds)

Kris Thielemans kris.f.thielemans at gmail.com
Thu May 4 17:13:02 EDT 2017


Hi

 

Short question: if we have a library/include files installed both in the
usual system locations and outside, how do we force CMake to find the
latter? (without modifying the CMake files of the project).

 

Motivation:

We're trying to make a SuperBuild that builds/downloads a specific version
of various packages (such as Boost and GTest). Our motivation is to have
complete control of the version. We don't want to install this in standard
locations to avoid clashes, root permissions etc.  So let's say we install
our versions in ~/our_stuff/lib, ~/our_stuff/include etc

 

It seems very hard (and sometimes impossible) however to let future
find_packages find our own versions as opposed to the system ones. From
https://cmake.org/cmake/help/latest/command/find_library.html I thought that
doing something like this would work

 

cmake ../ -DCMAKE_INSTALL_PREFIX=~/our_stuff

 

but the system version of boost etc are still found first (it does work if
there is no system version of the library). In the case of Boost, even 

 

cmake ../ -DCMAKE_INSTALL_PREFIX=~/our_stuff -DBOOST_ROOT=~/our_stuff

 

doesn't help (tested on Linux). I have to set BOOST_INCLUDEDIR for instance.
As every Find*.cmake has its own conventions of specifying cmake/environment
variables, and some don't at all, this just gets unfeasible.

 

I know about NO_DEFAULT_PATH, NO_CMAKE_SYSTEM_PATH etc options for
find_package, but this would need modification of CMake files in the
dependent packages which is quite undesirable for us.

 

Any suggestions?

 

Thanks

Kris

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170504/bf504d83/attachment.html>


More information about the CMake mailing list