On Monday 20 May 2013, Stephen Kelly wrote: > Brad King wrote: > > What's so bad about the exported targets being called "boost_..." > > instead of "boost::..."? > > A stronger indication that it is an imported target. boost::... can only be > an imported target, but boost_... could be an imported target, a in-build > target or a library. > > As we discussed in another thread, we can check for '::' to see if it is an > imported target and error if that imported target is not available. > > > VTK and ITK have worked that way for years. > > It is simpler if the name inside the upstream build matches that in > > the downstream consumers. > > Why is that simpler? > > By the same logic, is it simpler for the target name to match the output > name? Should the OUTPUT_NAME property exist?
OUTPUT_NAME does make things more complicated when used, but sometimes it is necessary. In KDE this was the case when converting to cmake, and names of produced files were not allowed to change. E.g. somewhere we had a library libkfoo.so and an executable kfoo. Both target names would be "kfoo" in cmake, so here via setting the OUTPUT_NAME it was possible to keep the name of the files on disk unchanged while having separate names for the two targets. > > We had some recent discussion about encouraging the convention of > > "namespace::" for imported targets, but perhaps we should reconsider IMO encouraging/recommending this is good. This is much strong less than producing an error if it is not used. > > the value and cost. > > value: > * We can assume that NS::foo is an imported target and error if not found Since it was never forbidden and not even officially recommended to use "::" when exporting targets, I'm not sure the "::" should be used for the decision whether an error is generated or not. Also, the "::" is only a strong indication, not more. E.g. I can build the attached example using the ninja generator. > * Readers know that NS::foo is imported and tll(bar NS::foo) does more Yes. Those two are advantages of using a namespace when exporting targets. This can be done already right now. And as I said already before, I would not recommend using imported target names directly. How about extending readme.txt and recommend that Config.cmake files additionally to Foo_INCLUDE_DIRS and Foo_LIBRARIES also set Foo_TARGETS if they create imported targets ? > cost: > * Projects may wish to have a different in-build name than exported name. Why ? Alex
colcol.tar.gz
Description: application/compressed-tar
-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
