Thanks, Alan, I'll give some of that a shot and see what we can come up with. 
Learning about another
project that uses CMake (PLplot) that we can look at for examples and 
inspiration helps, too.

>From what I can tell, the stuff you mentioned seems to still rely on actually 
>building and
installing ProjectA on the build system for ProjectB -- the paths that CMake 
writes to the config
file will be absolute paths, correct? Thus, we couldn't just do a build and 
install of ProjectA on
one system, and copy the install tree into version control, because depending 
on how another user
has things mapped from version control to disk, the absolute paths in the 
config file likely won't
be correct.

Assuming we want to just put the install tree in version control somewhere, and 
have ProjectB's
list files reference the install tree out of version control, is writing a Find 
module the best way
to do that?

Matt

-----Original Message-----
From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] 
Sent: Thursday, December 01, 2011 6:13 PM
To: Matthew LeRoy
Cc: 'cmake@cmake.org'
Subject: [POSSIBLE SPAM] Re: [CMake] Best practices/preferred methods for 
linking external libraries
Importance: Low

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

Reply via email to