[CMake] The tao of find_package

Michael Hertling mhertling at online.de
Sat Oct 8 02:02:29 EDT 2011


On 10/08/2011 07:03 AM, Dan Kegel wrote:
> Hi folks,
> I'm just starting to play with cmake.  (I've used autotools, make,
> scons, and gyp before.)  I've been looking at the docs off and on for
> a couple days, playing
> with toy examples and building a few things already converted to cmake.
> 
> The project I'm building consists of about ten separate libraries.
> They used to have one (shaky) Makefile / xcode / visual studio project
> per platform, but we're looking at using cmake to try unifying things.
> 
> At first we just wrote one CMakeLists.txt for each library, wrote a
> FindXXX.cmake for each, use find_package() everywhere, and drove
> the whole build with a shell script that invoked cmake and make once
> for each library.
> That's fine, but since the shell script doesn't do dependencies, it's not
> very efficient.
> 
> Now we're trying to replace the shell script with a ueber-CMakeList.txt that
> just does add_subdirectory() on the ten libraries.  The question is:
> find_package() appears to be designed for finding *things that are already built
> and installed*, not other libraries you might have to build in the
> same make session.
> 
> Am I right in assuming that things I might want to build with my one big 'make'
> shouldn't be located with find_package()?

Exactly, FIND_PACKAGE() and find modules are intended to inform *your*
project about *other* projects which were already built and installed.
Therefore, you should definitely use ADD_SUBDIRECTORY() to tie up your
project's subdirectories and add a top-level CMakeLists.txt file that
governs the whole thing. In this manner, you can make use of CMake's
capabilities to track dependencies throughout the entire project as
long as you specify any immediate dependencies correctly.

> Thanks,
> Dan

Regards,

Michael


More information about the CMake mailing list