[cmake-developers] find_package without REQUIRED can cause fatal error now

[chris]

Brad King <brad.king at ...> writes:

> 
> On 07/31/2012 03:54 PM, Alexander Neundorf wrote:
> > On Tuesday 31 July 2012, Brad King wrote:
> >> I think a better solution is to allow specific package locations
> >> to be explicitly disallowed by the user. This gives them an
> >> option to deal with broken packages if they are not an admin
> >> on the machine capable of fixing it.
> > 
> > They can already right now set CMAKE_DISABLE_FIND_PACKAGE_≤package> to TRUE.
> > 
> > Is this good enough ?
> 
> Yes, I think so.  If a user wants a specific non-broken package to
> be used then s/he can set <package>_DIR to that location to skip over
> the broken one.  If the user wants to disable the package then this
> setting provides that option.
> 
> > (the documentation for this is at the very end of the find_package()
> > documentation, maybe it should move up to one of the first paragraphs.
> 
> There is a lot of documentation in find_package.  Something has to
> be at the end.  We can't repeatedly move up each thing that happens
> to seem most pertinent at the moment.
> 
> Anyway, a user encountering such failure may be just trying to build
> some software and not have written any CMake code.  They will not
> think to look at the documentation of find_package for a solution.
> The failure message would have to suggest the solution.  Perhaps we
> just need to teach find_package to detect when the package is found
> but the package configuration file generates an error.  If the
> package is optional it can generate a message suggesting use of
> CMAKE_DISABLE_FIND_PACKAGE_≤package>.
> 
> -Brad
> --
> 
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
> 
> 


I found this thread while searching for a resolution to my problems

For a quick backgrounder

I am trying to build several packages using emerge on windows XP. I am on
the current master branch in emerge but have also tried the stable kde-4.10
branch

Because windows has an issue with short command parameters I have enable
short paths in emerge. basically this assigns a drive letter to a folder and
reduces the chance of this issue causing problems

for example my short names are

KDEROOT           r:\kderoot
KDECOMPILER       mingw4
KDEGITDIR         q:\
DOWNLOADDIR       t:\


If I build with these subst drives I get errors like the one below. If I
don't I get other harder to trace errors

when building packages I get errors like the following...



-- Found KDE 4.10 include dir: r://include
-- Found KDE 4.10 library dir: r://lib
-- Found the KDE4 kconfig_compiler preprocessor: r://bin/kconfig_compiler.exe
-- Found automoc4: R:/bin/automoc4.exe
CMake Error at /lib/cmake/KActivities/KActivitiesLibraryTargets.cmake:68 
(message):
   The imported target "kactivities" references the file

      "//lib/libkactivities.dll.a"

   but this file does not exist.  Possible reasons include:

   * The file was deleted, renamed, or moved to another location.

   * An install or uninstall procedure did not complete successfully.

   * The installation package was faulty and contained

      "/lib/cmake/KActivities/KActivitiesLibraryTargets.cmake"

   but not all the files it references.

Call Stack (most recent call first):
   /lib/cmake/KActivities/KActivitiesConfig.cmake:18 (include)
   r:/share/apps/cmake/modules/MacroOptionalFindPackage.cmake:32 (find_package)
   CMakeLists.txt:14 (macro_optional_find_package)



Just to be perfectly clear the above "missing" dependency does actually
exist and is where it should be.

The problem appears to be that cmake is not searching where it should. Now I
do not know if this is a cmake issue or the maintainers of the individual
libraries (multiple libraries fail this test) or if its a kde-win issue I am
pretty new to this.

It would appear that cmake is not prepending the paths when searching for
resource it should actually be searching for 
"r://lib/libkactivities.dll.a" 

as this "optional" test fails the build stops

I am using cmake version is 2.8.11-rc1


Where should I look to resolve this issue?


Kind Regards
Chris