On Tuesday 18 December 2012, Stephen Kelly wrote: > Alexander Neundorf wrote: > > 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. > > Do you mean as compiler defintions, or as cmake variables set in the Config > file with set() ? I'll assume the latter.
Yes. > > 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 ? > > Yes, I suppose. However, I don't see the point. 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. > We can also turn it around. > Consider what would happen if my patch wasn't applied: > > find_package(Foo 2.0) > > find_package(Foo 1.0) > > if (FOO_MAKE_IT_COOL) > # Why is this always true, even though I use find_package Foo 2.0? > # Oh, right, I use find_package Foo 1.0 after that and that overwrites. > # Conclusion: If using different versions of the same package, I have to > # do so in independent directories. > endif() > > > 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. 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
