[CMake] find_package and CMAKE_INSTALL_PREFIX

[Michael Wild]

On 19. Oct, 2010, at 9:22 , Maik Beckmann wrote:

> This is not a question but a finding during a debugging session I like to share and a documentation enhancement request.
> 
> We have a number of projects that reside in different repositories including library projects that are chained up by find_package in conjunction with -config.cmake files that each library projects installs.  So far we just had this rule:
>  The N project builds are independent from each other. All they share is a common CMAKE_INSTALL_PREFIX
> 
> This strategy has proven to reliable and even noob proof.
> 
> Now we started installing our packages on the system and keep working on the development version independent from these installation.  Which caused some trouble...
> 
> If Proj-libFoo is installed to /usr, Proj-libBar depends on it and is configured with
>  -DCMAKE_INSTALL_PREFIX=$HOME/projects/install
> it will pick the one in /usr.
> It took me some time to figure where CMAKE_INSTALL_PREFIX is injected into the list of prefixes to consider by find_package: CMAKE_SYSTEM_PREFIX_PATH in cmFindPackageCommand.cxx
>   this->AddCMakePath("CMAKE_SYSTEM_PREFIX_PATH")
> CMAKE_SYSTEM_PREFIX_PATH holds a list of prefixes (/usr/local, /usr,...) where CMAKE_INSTALL_PREFIX  is the last entry.
> 
> That's the reason why our "just point the project to the others by using CMAKE_INSTALL_PREFIX" rule fell apart.
> 
> The fix is easy: just set CMAKE_PREFIX_PATH to the same location that CMAKE_INSTALL_PRFIX is set to.
> 
> 
> Guys, please add the role that CMAKE_INSTALL_PREFIX plays for find_package to the docs.
> 
> 
> Thanks,
> Maik

While I agree that it should be added to the documentation of find_package, it is what most people would expect (except when they get bitten by it). Most people would be pretty stumped if CMake wouldn't search in the installation prefix. 

My 2 cents...

Michael

--
There is always a well-known solution to every human problem -- neat, plausible, and wrong.
H. L. Mencken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101019/eefb6804/attachment.pgp>