[CMake] Building a library with a complex hierarchy

[Alan W. Irwin]

On 2006-07-25 03:00+0200 Tilo Wiklund wrote:

> My first thought was to compile all the different parts into their own
> libraries and then link them all into a common shared one. This,
> apperently, wasn't possible and maybe not a very clever way to do it.
> Simply having a ADD_LIBRARY with all the source files would look very
> ugly, and be error prone.

I would go for a multiple libraries approach, and have them link to each
other.  However, with this approach you have to be careful of the direction
of dependencies so that you avoid cross-dependencies or circular
dependencies between libraries. So for example, if liba depends on libb
(i.e., libb resolves symbols in liba), and libb depends on libc, then you
cannot have libc depending back on libb or liba, and libb cannot depend on
liba.  Also, you should consider whether certain parts of your project would
best by dynamically loaded using plug-ins (i.e., the library or executable
optionally loads the plug-in at run-time at user request rather than the
run-time loader always loading all components of the project software).

The PLplot project went through this sort of assessment several years ago.
It was a lot of work, but well worth it in the end.  The result is a
lean/mean shared core library which does nothing but core plotting
functions, a number of languages interfaces which are implemented as shared
libraries which link to the core library, and a lot of different plotting
device plug-ins.  Each plug-in is dynamically loaded by the core library
only if the user requests that particular device.  And, yes, we historically
implemented all of this with autotools, but my project to also do the same
with cmake is nearly finished, and I quite like the results (especially the
speed!)

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); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________