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 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

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 

Follow this link to subscribe/unsubscribe:

Reply via email to