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

[Stephen Kelly]

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.

> 
> 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. 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).

Thanks,

Steve.