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

[Alexander Neundorf]

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