[cmake-developers] Issuing errors for faulty INTERFACE_INCLUDE_DIRECTORIES

[Alexander Neundorf]

On Tuesday 26 March 2013, Brad King wrote:
> On 03/26/2013 02:53 PM, Robert Maynard wrote:
> > My concern with this feature is the use case of a directory not existing
> > at configure time, but which will exist at linking time. Primarily this
> > would occur when an imported library is the result of an
> > add_custom_command call which creates a new directory. While this might
> > be an edge case, I was wondering if we should have a way to skip the
> > verification on a target.
> 
> It is not an edge case.  The add_dependencies command explicitly supports
> adding "dependencies" of an imported target that then transitively become
> dependencies of real targets that use it.  The idea is to have a hand-made
> imported target that references files that will be produced at build time
> by something like ExternalProject.  The hand-made imported target would do
> 
>  add_dependencies(imp_tgt ep_tgt)
> 
> to get build-time dependencies right.  However, that will also mean that
> if one defines INTERFACE_INCLUDE_DIRECTORIES on imp_tgt the paths may not
> exist during CMake configuration.
> 
> I suggest that to support this case we allow the hand-made imported target
> to request that the include interface not be validated:
> 
>  set_property(TARGET imp_tgt PROPERTY
>    INTERFACE_INCLUDE_DIRECTORIES_ALLOW_MISSING 1)
> 
> Ideas for a better name?
> 
> Alternatively one could solve this case with no additional CMake feature
> by hiding the needed paths in $<1:...> generator expressions.  That is not
> as explicit, but I would be okay with that as the recommended solution over
> an awkwardly named property.

Probably I'm missing something obvious... can't the include-directories be 
checked by generating code into the exports-file ?
That's done for the other referenced files too.

Alex