On 2011-12-01 21:56-0000 Matthew LeRoy wrote:
We began using CMake a few months ago for a couple of small cross-platform
projects, and we're still
learning all the ins and outs and capabilities CMake has to offer, as well as
how to get the most
out of CMake by using it "The Right Way". Right now, we're trying to figure out
how to link
to external libraries that don't have "find" modules or CMake config-mode
files. After lots of
reading in the wiki, mailing list, etc, it seems like there are several
different ways to do
this, like writing "find" modules and/or config-mode files ourselves, using the
LINK_DIRECTORIES()
command, importing/exporting targets, and others. What we're unsure of is, what is the
"preferred"
or "officially supported" method?
To be a little more specific, we have two different library projects (call them
ProjectA and
ProjectB) that both use CMake, but are developed independently. Further,
ProjectB depends (or will
depend) on ProjectA; we've just recently gotten to the point on ProjectB where
we want to use some
of the functionality in ProjectA, so we need to link to the ProjectA
library(ies). At first we
thought we needed to write a "find" module for ProjectA -- but we really have
very little idea how
to go about doing that. Other than the wiki page for finding libraries that
talks a little about
writing "find" modules (http://www.vtk.org/Wiki/CMake:How_To_Find_Libraries),
is there any other
documentation for writing a proper "find" module? Is there a particular module
that ships with CMake
that is well-written that we should look at as a guide?
Then we came across the wiki page for module maintainers
(http://www.itk.org/Wiki/CMake:Module_Maintainers), which states in the
Introduction that we
should *not* write find modules for packages that themselves build with CMake,
and instead to create
a CMake package configuration file. We followed the link to the tutorials on
CMake Packages, but
don't fully understand everything that's going on there. Regardless, is this
the preferred method?
Another general question we have is that we may not want to have to build and
install ProjectA in
order to build ProjectB; we may instead just want to provide pre-built binaries
and headers for
ProjectA in ProjectB's source tree in version control -- part of the reason for
this is to control
which version of ProjectA is used by ProjectB. In that case, how would a find
module or
package configuration file find the binaries and headers, since they're not
installed in the
standard install location on the system? Further, regarding "standard install
locations": is there a
particular standard location to install packages on Windows systems, similar to
/usr/local (or
whatever install prefix is specified) on a Unix/Linux system?
Thanks in advance for whatever direction/guidance you can give!
If both ProjectA and ProjectB are built with cmake and ProjectB's
libraries depend on ProjectA's libraries, then use the EXPORT
signature for install(TARGETS ... for each library in A, and use the
install(EXPORT ... command _once_ for A. For example, PLplot has the
following cmake logic to do this:
install(TARGETS plplot${LIB_TAG}
EXPORT export_plplot
ARCHIVE DESTINATION ${LIB_DIR}
LIBRARY DESTINATION ${LIB_DIR}
RUNTIME DESTINATION ${BIN_DIR}
)
(and similarly for all our installed libraries) and there is also the
following line:
install(EXPORT export_plplot DESTINATION ${DATA_DIR}/examples/cmake/modules)
which installs the required information for all of PLplot's libraries in
that location.
Then all B has to do is set CMAKE_MODULE_PATH appropriately then use
the include command to gain access to the exported information for all
installed libraries from A.
For example, the installed examples for PLplot (which have their own
independent CMake-based build system) we use
set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake/modules)
include(export_plplot)
to get access to the required build information for the installed
libraries for the core build.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
--
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
