[cmake-developers] Making Config.cmake files safer

[Alexander Neundorf]

On Saturday 12 November 2011, David Cole wrote:
> On Sat, Nov 12, 2011 at 2:48 PM, Alexander Neundorf <neundorf at kde.org> 
wrote:
...
> "which is vague enough"
> 
> My problem with the message is that it is vague.

Possible reasons:
- somebody manually copied/deleted/renamed the files
- a non-development package was installed which contained the Config.cmake 
file, i.e. a broken package
- a "make install" or a "make uninstall" did not finish for whatever reason
- other weird things ?

The generated exports file does the following:

FILE(GLOB CONFIG_FILES "${_DIR}/BarTargets-*.cmake")
FOREACH(f ${CONFIG_FILES})
  INCLUDE(${f})
ENDFOREACH(f)

I'm not 100% sure there can't be scenarious during development or updating 
systems where suddenly an old previously installed file is included, but 
because targets were added or removed or configurations changed or renamed no 
matching library is there.

So, IMO it's hard to give advice what to do.
 
> It should tell the user what to do to resolve the problem. Otherwise,
> if we cannot tell the user what to do, we should just say "imported
> target file does not exist" and name the file.
> 
> We should not say things like "your installation is broken" or "there
> must be a problem" -- that tells the user NOTHING useful, and is just
> plain annoying. If we can't name the project/package whose
> installation is broken, then we shouldn't say "the installation is
> broken."

We can only know the name of the file, e.g. FooLibraries.cmake.
In many cases "Foo" will also be the name of the package in cmake language, 
i.e. there will be a FooConfig.cmake, but this is not guaranteed.
Whether the package under Windows or Linux has that exact same name, is yet 
another question.

I think I'll wait with this until Monday or so, Brad probably also has an 
opinion.

Alex