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

[Stephen Kelly]

Alexander Neundorf wrote:
> 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.


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

The only sane way I can see is to expect the caller to manage their own 
scopes.

It is possible to use an INHERITED property, as I wrote in the start of this 
thread 

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5410

but your downstreams still have problems if they do not manage their scopes.

 find_package(KArchive 5.1)
 find_package(KArchive 5.2)

If you add a guard, you can make the second find_package have absolutely no 
effect. Is that what the caller intended?

The only sane choice is for the caller to manage their own scopes.

Thanks,

Steve.