On 2018-03-08 12:49-0800 Alan W. Irwin wrote:
On 2018-03-08 20:05+0100 Nils Gladitz wrote:
On 08.03.2018 19:50, Alan W. Irwin wrote:
So what are the actual benefits of namespacing the exported targets
associated with libraries?
On the consumer side it makes linking to targets less error prone.
When you link to a library target without a namespace and e.g. get the name
or scope wrong CMake will silently assume that you want to link a library
by name (e.g. in context of gcc "foo" becomes "-lfoo").
When the library and its headers happens to be in the compiler's standard
search directories this might not even get caught at build time right away.
When the library target has a namespace CMake will require the given name
to be a target and will fail during generation if the target is not
actually available.
Hi Nils:
Thanks for that explanation which convinced me this particular "best
practice" is worth implementing along with the rest mentioned in
<https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/>.
Hi Nils:
Here are some further questions about best practice with regard to
namespaced targets. The three different build systems I am updating
in this regard have some common CMake code between the build-tree and
install-tree cases (to build examples and run various commands for the
two cases) so for that common code I need to use a namespaced ALIAS
library for the rather large number of libraries and modules (e.g.,
PLplot device driver dll's) that are built by those three projects in
order for the namespaced targets to also be available in the
build-tree case.
But since I am already going to the trouble of creating those ALIAS
libraries for each of my real libraries and modules, what is best
practice for use of those ALIAS libraries and modules in the build
tree?
For example, should I just confine their use to common
target_link_libraries and add_dependencies commands for the build-tree
and install-tree cases?
Or would you recommend I expand their use further for the build tree
case alone? For example, would you recommend the following change:
OLD method:
add_library(a ...)
add_executable(b ...)
target_link_libraries(b a)
NEW method (where <namespace> would be one of PLPLOT::, EPHCOM::, or
TE_GEN:: depending on project):
add_library(a ...)
add_library(<namespace>a ALIAS a)
add_executable(b ...)
target_link_libraries(b <namespace>a)
?
This *could* be considered best practice since similar motivations
apply ("a" could be the name of a system library so using <namespace>a
as a target_link_libraries item *could* find a build system bug (where
some naive build system developer was happily referring to what he
thought was an internal library when in fact the system version was
being used because of some misspelling issue when creating the
library.) But I think such misspelling issues would be quickly found
for build systems in any case so my feeling is you will say this is
"one step too far" since there is lots of editing involved (for all
code, not just the common code) for very little added benefit.
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.
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
__________________________
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
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
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
