Alexander Neundorf wrote: > The point is that you get targets from one installed Config.cmake file, > and other information from a different installed Config.cmake file, due to > different required version or search paths.
>> > Should we guard the whole Config.cmake file ? >> >> A Config file author could choose to do that, but if only broken code >> would break on it, that is up to the config file author to decide whether >> to maintain that kind of thing (and its complexity). > > I am not arguing against your patch. > I am just unsure how to handle the whole thing the best way. The only sane way I can see is to expect the caller to manage their own scopes. It is possible to use an INHERITED property, as I wrote in the start of this thread http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5410 but your downstreams still have problems if they do not manage their scopes. find_package(KArchive 5.1) find_package(KArchive 5.2) If you add a guard, you can make the second find_package have absolutely no effect. Is that what the caller intended? The only sane choice is for the caller to manage their own scopes. Thanks, Steve. -- 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
