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
_______________________________________________
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
