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