[cmake-developers] Generating guards around add_library(... IMPORTED)

[Alexander Neundorf]

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