My $0.02..I just completed a CMake system for a code project that
required several TPLs (third party libraries) two of which were the
NetCDF and HDF5. I struggled with the same problems you mention here.
When I wrote my FindXXX modules, the standard I adopted was,
XXX_INCLUDE_DIR only contained the path to the XXX include directory
while XXX_INCLUDE_DIRS contained XXX include directory any other TPL
include directory required to compile. Parts of the code was calling
NetCDF directly but not HDF5. I wanted the project CMakeLists.txt files
to be as clean as possible and placed the logic to determine if NetCDF
had HDF5 and adjusted the NetCDF_INCLUDE_DIRS if needed in our
FindNetCDF module. This allowed the developers to simply put
find_package(NetCDF)
include_directories(NetCDF_INCLUDE_DIRS)
in their CMakeLists.txt files not worry about testing for HDF5, etc.
This complicated the FindNetCDF module, but I think it improved the
stability of our CMake system.
If you decide not to cascade, then you will need to provide a flag like
you mention in (1) to help out whoever calls your module, so they can
call find_package(HDF5) when needed.
When NetCDF split the language APIs, I used the FindMPI module as a
template and created NetCDF_C_* NetCDF_CXX_* NetCDF_Fortran_* variables
in the FindNetCDF module. You may what to look at how that module
handles different language libraries and include directories for
inspiration.
Good luck!
On 12/12/12 17:35, esatel wrote:
Hi all,
I am trying to adapt an existing FindNetCDF.cmake file to work with NetCDF
4.2. I have read the Modules/Readme.txt but I am still a little unclear to
the best approach in my case.
In 4.2 the Fortran bindings and C bindings are not necessarily installed in
the same place. One motive for NetCDF_INCLUDE_DIRS to be plural is that
there might be a NetCDF_C_INCLUDE_DIR and a NetCDF_Fortran_INCLUDE_DIR that
together form NetCDF_INCLUDE_DIRS.
There is a second motive that I am less clear on. The FindNetCDF.cmake files
I have seen handle the HDF5 dependency differently:
1. One sets a variable NETCDF_HAS_HDF5 by querying a config executable but
does nothing else.
2. The other sets a similar variable but then does find_package on HDF5 and
loads the dependencies into NetCDF_INCLUDE_DIRS and NetCDF_LIBRARIES.
This design (2) cascades. FindHDF5.cmake represents a similar decision about
whether to find_package its dependencies like the zlib compression library.
I believe the one in the cmake distro doesn't do that.
What is the best practice here? To handle dual locations for the library at
hand or to accumulate or both? The first seems unavoidable ... the second
seems to be an unevenly applied standard.
Thanks
Eli
--
View this message in context:
http://cmake.3232098.n2.nabble.com/Why-is-XXX-INCLUDE-DIRS-plural-and-should-it-be-deep-tp7582623.html
Sent from the CMake mailing list archive at Nabble.com.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Lori A. Pritchett-Sheats, PhD.
CCS-2, Computational Physics and Methods
Office: 505-665-6675
Fax: 505-665-4972
Los Alamos National Laboratory
P.O. Box 1663
MS D413
Los Alamos, NM 87544
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
