Re: [cmake-developers] Kind-of standard way to support also in-project find-modules
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
Re: [cmake-developers] Kind-of standard way to support also in-project find-modules
On Tue, Jan 11, 2011 at 11:55 PM, Brad King brad.k...@kitware.com wrote:
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()
What about something like this?
if( FOO_USE_LOCAL_BAR)
set( CMAKE_PREFIX_PATH ${PROJECT_SOURCE_DIR}/3rdparty )
endif(FOO_USE_LOCAL_BAR)
find_package(BAR)
It searches the local directory first, then goes for system. Looks easier to me.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Kind-of standard way to support also in-project find-modules
On 01/11/2011 06:13 PM, Pau Garcia i Quiles wrote:
What about something like this?
if( FOO_USE_LOCAL_BAR)
set( CMAKE_PREFIX_PATH ${PROJECT_SOURCE_DIR}/3rdparty )
endif(FOO_USE_LOCAL_BAR)
find_package(BAR)
It searches the local directory first, then goes for system. Looks easier to
me.
The FindBAR.cmake module is looking for a binary installation of BAR,
as in lib/libbar.a or bin/bar. The source tree does not provide
this so is not an appropriate place to look.
-Brad
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Kind-of standard way to support also in-project find-modules
On Wed, Jan 12, 2011 at 12:18 AM, Brad King brad.k...@kitware.com wrote:
On 01/11/2011 06:13 PM, Pau Garcia i Quiles wrote:
What about something like this?
if( FOO_USE_LOCAL_BAR)
set( CMAKE_PREFIX_PATH ${PROJECT_SOURCE_DIR}/3rdparty )
endif(FOO_USE_LOCAL_BAR)
find_package(BAR)
It searches the local directory first, then goes for system. Looks easier to
me.
The FindBAR.cmake module is looking for a binary installation of BAR,
as in lib/libbar.a or bin/bar. The source tree does not provide
this so is not an appropriate place to look.
Oh, OK. I thought this was for the case you want to distribute the
third-party binaries you use to develop your application (we do that
internally).
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
