[cmake-developers] Adding automatic checks for required targets in target-export files ?

[Brad King]

On 02/12/2013 01:47 PM, Alexander Neundorf wrote:
> One thing is, the Config.cmake file itself could set the policy to NEW or OLD.

Yes, but it shouldn't.  That can be documented in the policy docs.

> But IMO the policies should be controlled by the consuming project, not by the 
> used projects.

Of course.

> Also, the NEW mode, i.e. fail at cmake time, would only be active for projects 
> which require 2.8.11, for others it would just be a warning at cmake time, and 
> a failure at build time.

That's called backward compatibility with existing behavior for existing projects.
It's the entire point of policies.  Yes, there is a transition period and not
everyone will benefit right away, but no existing users will be hurt either by
having their already-working projects break.

The upstream will have to have been built with 2.8.11 for the new code to be
in the target files anyway.  The consumers not requiring 2.8.11 will get warnings
instead of errors but at least the information will be there.  They can also add

 if(POLICY CMP00xy)
   cmake_policy(SET CMP00xy NEW)
 endif()

to get an error without otherwise requiring 2.8.11.

> 1) fail immediately in the targets file if a referenced target does not exist 
> yet. If imported targets would be new, I would do this. But since they already 
> exist for some time, there are most probably projects where the order of 
> find_package() does not take the dependencies into account, so they build now, 
> but would fail at cmake time then. Would that be acceptable ?

This is the same as your previous proposal #1.  I accepted it already but
require the policy for compatibility.

> 2) Collect the referenced imported targets and check later whether they all 
> have been imported, and error out if not.
> I'm not completely sure when "later" is.
> First I thought at the end of the configure-step, but since imported targets 
> do not have global scope, I think this has to be done per directory. So I 
> could do this check in some way at the end of processing a CMakeLists.txt, 
> i.e. before leaving a directory.

This may be a better option with some C++-side support because it will not
require projects to change an already-working out-of-order import.  It
would also potentially allow circular dependencies to work.  One could define
a directory property that targets files can populate.  It is simply a list
of target names that must exist by the time the directory is done:

 set_property(DIRECTORY APPEND PROPERTY REQUIRED_TARGETS ...)

CMake can read this property at the end of a directory and produce an
error if it is not satisfied.

-Brad