[cmake-developers] Issuing errors for faulty INTERFACE_INCLUDE_DIRECTORIES

[Alexander Neundorf]

On Thursday 28 March 2013, Brad King wrote:
> On 03/27/2013 05:21 PM, Alexander Neundorf wrote:
> > Maybe instead of generating code which immediately results in failure at
> > the find_package() step, how about generating code which contains a list
> > of imported targets with missing dependencies/files/directories ?
> 
> This is blowing the proposed feature way out of scope.  Currently there
> will be no error until build time.  

... when using Config.cmake files, which are only starting to get commonly 
used, and I have seen plenty of mistakes in existing Config.cmake files. 
Usually it is already hard to explain to developers the fundamental difference 
between Find-modules and Config.cmake files.
Currently when using Find-modules, you get proper error reporting from 
find_package().

> With the proposed feature the error
> will be at CMake time when there could have been one at build time, but
> not extra errors at CMake time that would not have occurred at build
> time.
> 
> >    if(Xxx_IMPORTED_TARGETS_WITH_MISSING_STUFF)
> >    
> >       set(Xxx_${comp}_FOUND FALSE)
> >    
> >    endif()
> 
> A package config file and consuming projects should not be expected to
> adapt to broken installations of packages to use the "non-broken" parts.
> If an include dir is missing who knows what else is wrong.
> 
> This feature should be about making things simpler by erroring out early
> when we know the build is likely to break because something is missing.
> Your proposal will make it more complicated by trying to adapt to the
> breakage.
> 
> BTW, take a look at this problem:
> 
>  http://www.cmake.org/Bug/view.php?id=14041
> 
> triggered by some of the existing checks for missing files.


Yes, but this is something we have to take care of (thanks for doing that), if 
we want developers to like Config.cmake files.
What I like about Find-modules is that they give reliable information about 
the actual state of the system. If a Find-module tells me jpeglih.h can be 
found in some directory, it actually exists there, if it tells me the path to 
a libjpeg.so, I can rely on that this file actually exists.

If find_package() "only" reads some cmake script file, i.e. a Config.cmake 
file, this doesn't give me those guarantees as long as this file does not 
verify that the information it provides is actually correct, by checking that 
the files and directories it reports to me actually exist.
This is a step backwards compared to Find-modules.
Config.cmake files are much more powerful than Find-modules, but they are also 
a lot more complex, at least for simple cases.
We should not add more disadvantages to them (like not actually being a 
reliable source of information).

I had enough of bad experiences with libtool la files, I want Config.cmake to 
be much much better.
For me, this includes that if we do not use find_library()/find_path() to 
actually introspect the system, we need to make sure that the files we refer 
to actually do exist, so that the contents of the Config.cmake files will 
hopefully never be the cause for build debugging by developers.

Alex