[cmake-developers] Kind-of standard way to support also in-project find-modules

Brad King brad.king at kitware.com
Tue Jan 11 17:55:53 EST 2011


On 01/11/2011 04:18 PM, Alexander Neundorf wrote:
> Well, there was the following commit in KDE for two module FindKExiv2.cmake 
> and FindKipi.cmake
> For both modules it adds a variable <UPPERCASED_NAME>_LOCAL_DIR, which can be 
> set if the using project doesn't use an externally installed KExiv2/Kipi, but 
> if it has its own copy.
> Then this variable should be set to the source directory of the included 
> KExiv2/Kipi, and the find-module will honor this and set the include 
> directories and library-variables accordingly.
> 
> I think this idea is not bad.

It is an interesting idea.  However, IMO the job of a find-module is to look
for something when the project doesn't know where it is.  It should stay
focused on that to keep the find-module simpler.  Certainly this type of
feature does not belong in any of the CMake-provided find-modules because
they will have no idea exactly the layout of how the third-party tool source
is included in the project source tree.

Typically we use code of this form:

  if(FOO_USE_SYSTEM_BAR)
    find_package(BAR)
  else()
    add_subdirectory(bar)
    set(BAR_INCLUDE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/bar/include)
    set(BAR_LIBRARY_DIRS ...)
    # ...set rest of variables normally provided by FindBAR.cmake
  endif()

I don't think the else() clause belongs in the find-module.  Otherwise
the above becomes:

  if(NOT FOO_USE_SYSTEM_BAR)
    add_subdirectory(bar)
    set(BAR_SOURCES_DIR ${CMAKE_CURRENT_SOURCE_DIR}/bar)
  endif()
  find_package(BAR)

While this looks shorter the extra complexity lies in FindBAR.cmake.
Furthermore, it works only when FindBAR.cmake comes in the source tree
of the project and knows information like where the "bar" subdirectory
keeps its include files.

-Brad



More information about the cmake-developers mailing list