[CMake] Patch: Add NO_CACHE option to find_xxx commands

[Timenkov Yuri]

On Monday 07 July 2008 10:26:49 Miguel A. Figueroa-Villanueva wrote:
> Hello,
>
> I would like to propose the addition of a NO_CACHE keyword to the
> find_xxx commands that would treat <VAR> as a non-cached variable. I
> have posted this as a feature request with an initial patch
> implementing it for the find_path command. For more information look
> at the feature request at:
>
> http://public.kitware.com/Bug/view.php?id=7290
>
> Thoughts?
There is a strange request in bug description: "In this case we would like to 
cache wxWidgets_LIB_DIR to allow the user to be able to modify it in the gui. 
Then wxWidgets_core_LIBRARY should be searched for in wxWidgets_LIB_DIR 
without allowing or presenting the user with the opportunity to select another 
version of the library rooted elsewhere."

User is always allowed to modify cache entries. In your case user has 2 
options: modify wxWidgets_LIB_DIR in cache and delete wxWidgets_core_LIBRARY 
in cache or just point wxWidgets_core_LIBRARY to proper file. And this will be 
impossible with NOCACHE option.

However, in first case user should know to delete dependent cache entry and 
this is annoying. I don't want to know in advance what variables I should 
specify in first CMake run, I just want to set them later in GUI dialog. 
Similar problems arises with using some pre-configuration options, like boost's 
Boost_USE_STATIC_LIBS or Boost_USE_MULTITHREAD.

There is not a problem for automated build system (in my case), because I can 
fine-tune such options in RPM spec and don't bother later. But when user checks 
out sources and tries to compile project first time he should know about 
possible options.

So, I suppose there should be either dependency between such options (generic 
solution as described in http://public.kitware.com/Bug/view.php?id=7286) or 
some kind of best-practices how to implement such features by playing with 
CACHE/INTERNAL options to detect first run or options changed by user.

>
> --Miguel
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake