[cmake-developers] Making Config.cmake files safer

[David Cole]

On Sat, Nov 12, 2011 at 3:38 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> 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.
>

Sounds like a good idea.

And, in my opinion, if there are multiple possible causes of the
problem.... then we should enumerate them in a message to the user,
just as you've done here in this email back to me. And we should try
to put them in the order of likelihood, so when they read it top-down,
they read the smallest amount possible before having the a-ha moment
where they realize what went wrong earlier.


Thanks,
Dave