[CMake] Help with find module for package w/ components

[Alan W. Irwin]

On 2018-02-23 22:27-0000 Zaak Beekman wrote:

> Is there a way to define a single target
> that can be passed to target_link_libraries() that will cause the
> *multiple* (imported) library archives of the base package to linked in?

Hi Zaak:

Imported library targets are handled similarly to ordinary library
targets.  So suppose you have a core library with the name core_fortran
and a c interface library with the name c_interface, then C code
should be linked to c_interface (which draws in core_fortran if you
are transitively linking but otherwise not) and fortran code should be linked
to core_fortran.

> Can I define it in such a way that it is namespaced like Foo::Foo?

I have never tried that myself, but 
from my (very recent) reading of
<https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/>
namespacing is done using the NAMESPACE option for the
install(EXPORT...) command.  N.B. that article is extremely useful
so I would recommend reading and re-reading it with care.

> For an optional component, then do I specify an additional target for that
> component?

CMake users can organize the export of CMake packages in essentially
any way they like.  For example, the PLplot build system I am helping
to maintain uses a deprecated paradigm where there is just one
exported package containing a very large number of different targets.
But this approach is deprecated since it makes life too difficult for
software distribution maintainers who typically like to split up the
various libraries and dll's installed by a project into several
different interdependent binary packages.  So it is very much on my
agenda to reorganize our single export of a CMake package into a
number of different exports with each of those CMake packages
containing a disjoint subset of our targets with appropriate
find_package commands in Config mode to import all CMake packages that
a given CMake package depends on.

So in your case, this new approach we intend to take would boil down
to you exporting a CMake package corresponding to your C interface library and a
CMake package corresponding to your core Fortran library.  And the C interface
library CMake package should use find_package to find the fortran core
library package your C interface library depends on. So if user code
depends on your C interface, they should use find_package in Config
mode to find your C interface library package which in turn
automatically finds your core Fortran library. But if user code is
Fortran only they should just import your core Fortran library CMake
package.  N.B. in both cases, the net effect is all targets are imported
that are needed.  But once those targets are imported then the use of
those targets in target_link_library commands is completely orthogonal
to exactly how the targets are organized into separate packages.

Anyhow, I hope this discussion (especially the above URL reference to best
CMake practices) is a help to you.

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
__________________________