[Plplot-devel] Namespaced ALIAS library targets which are the first step in planned CMake best-practice upgrades

[Alan W. I. <ir...@be...>]

Recently (commit 593c07f) I have introduced namespaced ALIAS library
targets (e.g., the target PLPLOT::plplot created by the

add_library(PLPLOT::plplot ALIAS plplot)

command where plplot is an ordinary library target created previously)
into our build system, and I plan to extend their use to modules
(CMake speak for dll's) as well.  I am also planning to use namespaced
library and module targets for our install-tree build system (by using
the NAMESPACE PLPLOT:: argument of the install(EXPORT ...) command).

N.B. these namespaced versions of the targets associated with our
libraries and dll's are read only (i.e., you cannot change their
properties).  And they do not change the actual names of the
associated library and dll files.  But according to recent help I have
gotten on the CMake mailing list, use of namespaced versions of
targets for libraries and modules are considered to be CMake best
practice because they make it possible to be safer when using the
target_link_libraries command.  For example, consider

target_link_libraries(mycode.c plplot)

versus

target_link_libraries(mycode.c PLPLOT::plplot)

The "plplot" in the former potentially could refer to the plplot
target (if that exists).  But if that target does not exist (because
the user forgot to find the PLplot package which creates that imported
target), then CMake will happily find the plplot system library (if
that exists) and use that instead. Such subtle errors are not possible
for the latter form since CMake recognizes that any item in
target_link_libraries that has a "::" in the name must be a read-only
IMPORT or ALIAS target so if that target does not exist an immediately
obvious CMake error occurs which should be easy to diagnose and fix.

In sum, I consider this commit to be the first in a long series trying
to upgrade our build system (whose implementation style is roughly
consistent with the CMake bad practices that existed a decade ago) to
modern CMake best practices.  For an extremely useful introduction to
those good practices see the simple build-system example and
associated description of it at
<https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/>.
That article had several examples of bad practice and the
corresponding good practice. So because those bad practices occur
extensively in our build system it appears that article is is going to
be my build-system bible for quite some time to come!

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
__________________________