On Saturday 09 February 2013, Alexander Neundorf wrote: > Hi, > > a few weeks ago I added the feature that within one project, you can export > depending targets into separate exports. > When doing that, cmake now automatically adds a check whether the required > targets (which were exported in a different export set) exist: > > if(NOT TARGET foolib ) > message(FATAL_ERROR "Required imported target foolib not found !") > endif() > > > This is nice. > > But this is not done for other required targets, which were imported > targets already in the exporting project (e.g. if libkcoreaddons has > Qt5::Core in its LINK_INTERFACE). > > IMO it would be nice if cmake automatically would create the same check as > above for targets from the same project. > I'm not sure whether this could cause build breakage... I think suddenly > the order of the find_package() calls would become more important, the > needed projects would have to be searched before... > > Or is that already done now in some branch ? > I lost a bit track of the other threads...
after having worked a bit more with depending projects which load each others exported targets, in the meantime I think this is a must, the exported target files must carry the information whether a name they use in the link interface is a library or a target, and cmake must fail if a target used there does not exist. Example: I played around with libkconfig, which depends on libkcoreaddons. Without the checking whether libkcoreaddons has been found already in the Config.cmake file, I successfully loaded kconfigConfig.cmake, which has "kcoreaddons" in its link interface. So the cmake run succeeded. It also compiled, because the headers were found. But when linking I got "could not find "-lkcoreaddons". This should not happen if the cmake finished successfully. No normal user will figure out why things are going wrong. I see two options: 1) either put a check for the required targets in the generated targets file, and make find_package() fail by setting foo_FOUND to FALSE. This should be relatively straightforward to implement, and needs only code in the generated targets file. This is good. On the downside, this will probably make the cmake run fail for (some ?) projects where it currently succeeds, although they do not take the dependency order into account when searching packages. 2) in the Config.cmake file, collect all referenced targets, and have a check at the end of the configure-step whether there are any referenced targets which have not been defined, and fail then. The good thing about this is that it will not break the cmake run of projects which are working right now, the downside is that the error message will probably be much less detailled than in the first case. I'd prefer option 1), even though it may mean some short-term pain. But maybe option 2) is already work in progress, since there was some talk about defined targets in the other thread ? Comments ? Alex -- 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