On Sunday 10 February 2013, Stephen Kelly wrote: > Alexander Neundorf wrote: > > 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. > > > > Comments ? > > Any response to my comment? > > http://thread.gmane.org/gmane.comp.kde.cvs/1209819/focus=1209828
Somehow I didn't get that email, neither on kde-frameworks-devel nor on kde- buildsystem. Maybe it went into the spam ? Whatever. > > +if(NOT TARGET KF5::kcoreaddons) > > + set(kconfig_NOT_FOUND_MESSAGE "kauth depends on the package > > kcoreaddons, which is missing. Use find_package() to find it before > > kauth.") > > + set(kconfig_FOUND FALSE) > > + return() > > +endif() > > + > > This doesn't seem to be the right approach. > > kauthConfig should contain > > find_package(kcoreaddons). Yes, I agree. Checking for the target was the quick way to make it succeed only if it will also build. I didn't take the time on Saturday to figure out which options to use and which variables (CMAKE_PREFIX_PATH etc.) to set when calling the internal find_package(). Another thing came to my mind. Let's say kguiaddons depends on kconfig, so it will do find_package(kconfig) I guess it should not search the packages kconfig depends on, but rely on kconfigConfig.cmake doing that. So far, so good. Now, if we have some optional libraries used in let's say kguiaddons, this may give a dynamic list of targets we depend on in the Config.cmake file. So I guess we have to propagate the used targets/package down to the top level CMakeLists.txt, which generates the Config.cmake file, and there configure some code into the Config.cmake file which can check (and find_package()) the actually used targets as necessary... Independent from that, as a safeguard, the exported target files should in some way make sure that they will really work. They now have already checks that the files their own libraries references actually exist, they have a check that the imported targets from within the same project exist, but they do not yet have a check that the needed imported targets from other projects exist too. This should be there to make sure cmake report "NOT FOUND" at cmake time when a needed target is missing instead of failing with "could not find - lkcoreaddons" at link time. 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