[CMake] What are the actual benefits of namespaced targets?

Alan W. Irwin irwin at beluga.phys.uvic.ca
Sun Mar 11 20:43:37 EDT 2018


On 2018-03-11 10:15+0100 Nils Gladitz wrote:

> On 10.03.2018 23:01, Alan W. Irwin wrote:
>> Anyhow, your thoughts would be appreciated for reasonable best
>> practice limits on how far (if any) beyond the common code case you
>> would go to convert an old project to use
>> ALIAS libraries and modules in the build tree that have to be
>> implemented in any case for CMake code that is common to
>> both the build tree and install tree. 
>
>
> Hello Alan,
>
> I agree with your assessments.
>
> Assuming a project that is highly structured through directory scopes I might 
> consider the following.
>
> Any target is defined in exactly one directory scope.
> Any command that extends the definition of a target has to use the original 
> target name and should be in the same directory scope.
>
> In all other directory scopes I'd consider consistent use of a target's 
> alias.

Hi Nils:

I think your suggestions prior to the last one above make perfect
sense, and as far as I know my three projects already conform to them.

But I have now considered your last suggestion (replacing read-only
library and module targets in the build tree with the relevant
namespaced target alias), but I have decided the cost/benefit ratio is
too high in the PLplot case.  The cost issue is PLplot has some 330
different build system files (those named "CMakeLists.txt", "*.cmake",
or "*in") and something like 30 different library and module targets.
An additional complication is all libraries include "plplot" in the
target name (including our principal library whose target name is
"plplot") but "plplot" also occurs in all sorts of other contexts in
those 330 files.  So making this change in the PLplot case would
require a massive mentally concentrated editing exercise for what I
think is a rather small and mostly stylistic benefit.  So for PLplot I
plan to limit use of namespaced targets to just the
target_link_libraries and add_dependencies commands that are common to
the build-tree and install-tree build systems.

In contrast to the PLplot case, the costs of your last suggestion are
much lower for the ephcom and te_gen cases (many fewer build-system
files, libraries, and modules) so in those cases I might go all the
way with converting the present read-only library and module targets
with namespaced targets.  And similarly when implementing new projects
since the costs are even lower in those cases.

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
__________________________


More information about the CMake mailing list