[CMake] Best practices/preferred methods for linking external libraries

[Alan W. Irwin]

Hi Matt:

On 2011-12-02 19:33-0000 Matthew LeRoy wrote:

> 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?

Yes.  Of course, you do have complete control of the installation prefix for
ProjectA.  So we can install PLplot with any such prefix, and the
independent CMake-based build system for those installed examples works
without issues.  But you don't have control of ProjectA's installation
prefix from ProjectB which is what I believe you are asking for.

> 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?

I don't see any way your highly unusual use case could work unless you
adopt a common installation prefix for projectA that everybody can use
on their various systems.

I think the EXPORT idea is designed for known installation prefixes.
The mainstream use case would be to release binary (and source)
versions of ProjectA.  Then those who use ProjectB could just install
the binary versions of projectA in the designated install prefix.  (Of
course, if they built ProjectA from source they would have complete
control over the installation prefix.)

By the way, why don't you use that mainstream use case yourself?  That
is, just develop projectA like an ordinary independent software
project with library soversions, releases, etc., to keep track of ABI
changes for each release that will affect ProjectB.

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
__________________________