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 __________________________ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
