On 2018-11-19 14:20-0000 rmawatson rmawatson wrote:
I am trying to figure out exactly what this line is for in the cmake file of the github json project here -> https://github.com/nlohmann/json/blob/develop/CMakeLists.txt#L48add_library(${PROJECT_NAME}::${NLOHMANN_JSON_TARGET_NAME} ALIAS ${NLOHMANN_JSON_TARGET_NAME}) Specifically with this example, what does this allow in this cmake file that otherwise would not be possible? The commit message where this line was added says, "Enable target namespaces and build dir project config CMake convention is to use a project namespace, i.e. Foo::, for imported targets. When multiple targets are imported from a project, this looks like Foo::Bar1 Foo::Bar2, etc. This adds the nlohmann_json:: namespace to the exported target names. This also allows the generated project config files to be used from the build directory instead of just the install directory." Removing this line appears to make no difference to any off the generated cmake files. I can still use find_package with the build directory in CMAKE_PREFIX-PATH with our without this line. Has something changed in cmake since this was added? I am using cmake 3.10.2.
No, ALIASed targets continue to be supported by the latest CMake because they are an important component of CMake best practices for name-spaced targets. Thus, unless you can prove it has no effect you should leave that ALIAS logic alone. For example, a common use case for ALIASed targets is to allow build-tree CMake logic to use the same name-spaced name for a project's build-tree targets as foreign projects use to import targets from that project. So to take one example, the PLplot standard examples are all linked against the target PLPLOT:plplot (our principal library). That target name refers to an ALIASed target in our build tree but is a simple imported namespaced target in our installed examples tree (which is set up as a foreign project that imports namespaced targets such as PLPLOT:plplot from the PLplot installation). Therefore this ALIASing allows us to use and maintain the identical CMake logic (where we literally install copies of some of our build-tree CMakeLists.txt files in our installed examples tree) for the two separate cases. If we removed our ALIASed targets in the build tree, that would not affect anything in our installed examples tree, but it sure would mess up our build-tree testing (which depends on our examples getting built in that case), and you may find similar build-tree test failures would occur for the project you are investigating if you removed the ALIASing logic. Alan __________________________ Alan W. Irwin 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
