Re: [cmake-developers] Question about ALIAS targets
On Monday, 5 June 2017 22:45:26 BST Stephen Kelly wrote: > Brad King wrote: > > Steve, is there any reason for the restriction other than not implementing > > more use cases up front? > > There may be more information in the mailing list archives, but as far as I > remember, yes - we wanted to be conservative because we didn't know more > use-cases. Additionally, we didn't know the impact of making the feature > more unrestricted. If you want to see an example use case, I found that c-ares were trying to ALIAS an IMPORTED library in their package config file to make it convenient for a downstream project to explicitly link against a static or shared library (if available), or link against "either" if they don't care: https://github.com/c-ares/c-ares/blob/97f8b14c/c-ares-config.cmake.in If c-ares is compiled with both static and shared options, it will produce c-ares::cares (shared) and c-ares::cares_static (static) exported targets. Otherwise, if only one of the static or shared options is specified, it will always just build and export a c-ares::cares target. Obviously, the code won't work (and there is a pull request to fix it by using INTERFACE libraries at https://github.com/c-ares/c-ares/pull/108), and you may argue that this isn't the right solution to present downstreams with a "static vs shared vs don't care" choice, but I thought it might be interesting to show what developers are wanting to do with this. Alex -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Question about ALIAS targets
>> After my find_package(OtherProj) call, which is a super build which >> defines lots of imported targets, I want the target to be named gtest >> to match its library name, but OtherProj has named it googletest. > > Why isn't there a standard name? Should upstream provide the imported > target? Has any effort been made to make upstream provide it? Is the name > from OtherProj namespaced? Why do you need it to have a particular name? Why > does OtherProj expose it? Should it expose that target for you to use (it > seems an internal thing to me)? > There is a standard name. "Upstream" in this case is a super build of many projects, with an imported target for each project named after the project that means "the main lib (or all the libs) in the project". Now, for projects that already have "good imported targets" (Qt, VTK), I don't bother creating imported targets, I allow client projects to link directly to those imported targets. But for projects that don't, I create a convenience imported target named after the project. In the case of googletest, the project name is named for its GitHub repo, but there is no library of that name and its install provides no imported targets. And the "main" library is just gtest. So I create an imported target named after the project, but in this case, I also want to create an imported target for each lib. So I do, but that means my googletest and gtest targets are essentially identical except for their names. ( ** i.e. aliases of each other, but both imported... ** ) I don't need it to have a particular name, but I want to follow a chain of naming conventions: naming the project after its repo, keeping an imported target for each project in my super build named after the project, and then, where it makes sense, also having per-library imported targets. I'm not expecting anybody to do any work on this, or to loosen the restriction for my convenience... I just wanted to know if there were a good reason for the error message. Sounds like "nobody needed it yet, and we were being conservative" is the answer. Which is a good answer. Thanks, David C. -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Question about ALIAS targets
On 06/05/2017 05:45 PM, Stephen Kelly wrote: > Eg - making it easy to alias imported targets means you can easily get > imported target names which vary per project (Qt5::Core, Qt5::QtCore, > TheQt5CoreLibrary etc) which doesn't seem useful. If we were to allow aliases of imported targets we'd also have to work out the scoping rules (global v. local). -Brad -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Question about ALIAS targets
Brad King wrote: > Steve, is there any reason for the restriction other than not implementing > more use cases up front? There may be more information in the mailing list archives, but as far as I remember, yes - we wanted to be conservative because we didn't know more use-cases. Additionally, we didn't know the impact of making the feature more unrestricted. Eg - making it easy to alias imported targets means you can easily get imported target names which vary per project (Qt5::Core, Qt5::QtCore, TheQt5CoreLibrary etc) which doesn't seem useful. An desire to be able to do that may just be a mask on an underlying problem. CMake doesn't need multiple 'equally good' ways to solve the same problem. Thanks, Steve. -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Question about ALIAS targets
David Cole via cmake-developers wrote: > Is there a good reason why this error must be an error? > > CMake Error at CMakeLists.txt:23 (add_library): > add_library cannot create ALIAS target "MyProj::gtest" because > target "OtherProj::googletest" is IMPORTED. > > The line of code is: > > add_library(MyProj::gtest ALIAS OtherProj::googletest) > > Why is there any restriction on ALIAS targets about what sorts of > targets they may be aliases of? They were introduced here: https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=370bf554151a1 Aside from the information there, other commits may have extended or tweaked the features/restrictions. > After my find_package(OtherProj) call, which is a super build which > defines lots of imported targets, I want the target to be named gtest > to match its library name, but OtherProj has named it googletest. Why isn't there a standard name? Should upstream provide the imported target? Has any effort been made to make upstream provide it? Is the name from OtherProj namespaced? Why do you need it to have a particular name? Why does OtherProj expose it? Should it expose that target for you to use (it seems an internal thing to me)? Thanks, Steve. -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Question about ALIAS targets
On 06/05/2017 04:10 PM, David Cole via cmake-developers wrote: > Why is there any restriction on ALIAS targets about what sorts of > targets they may be aliases of? Adding Steve (who added ALIAS targets) to Cc. The use case in the documentation: https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html#alias-targets is the only one that was really designed. It is for making in-project build targets available to other directories in the project under the same name that an externally-built project might see it as an imported target. This allows tests and examples to use the name that client code would. Of course only in-project build targets need to be aliased for this. Steve, is there any reason for the restriction other than not implementing more use cases up front? Thanks, -Brad -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Question about ALIAS targets
Is there a good reason why this error must be an error? CMake Error at CMakeLists.txt:23 (add_library): add_library cannot create ALIAS target "MyProj::gtest" because target "OtherProj::googletest" is IMPORTED. The line of code is: add_library(MyProj::gtest ALIAS OtherProj::googletest) Why is there any restriction on ALIAS targets about what sorts of targets they may be aliases of? After my find_package(OtherProj) call, which is a super build which defines lots of imported targets, I want the target to be named gtest to match its library name, but OtherProj has named it googletest. I can brute force this particular one to just be another IMPORTED target with all the same properties and property values as the original, but it seems to me this particular case should be allowed unless there's a fundamental problem I'm not aware of. Thanks for any explanations David C. -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
