On Tuesday 18 December 2012, Stephen Kelly wrote: > Alexander Neundorf wrote: > > With the return() in the FooTargets.cmake file, this included file will > > simply do nothing, and we'll stay with the "old" imported targets and > > their properties. > > But the FooConfig.cmake file which has just been executed may set a bunch > > of variables, which would fit to the targets which now have not been > > imported, and which do not fit to the previuosly imported targets. > > > > Should the FooConfig.cmake fail in this case ? > > Probably not. > > Can you post a code snippet showing the problem?
Let's say there is Foo 2.0 installed in /usr/lib/, and Foo 1.0 is installed in /usr/local/lib/. Both provide the imported target Foo::SomeLib. 2.0 has been built with FOO_MAKE_IT_COOL=FALSE, 1.0 has been built with FOO_MAKE_IT_COOL=TRUE. Now CMakeLists.txt does: find_package(Foo 2.0) find_package(Foo 1.0) If we guard only including the targets, won't we end up with the imported targets from 2.0, but with FOO_MAKE_IT_COOL=TRUE from 1.0 ? Should we guard the whole Config.cmake file ? But can't this also break some constellations ? 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
