[CMake] Patch: Add NO_CACHE option to find_xxx commands

[Alexander Neundorf]

On Monday 07 July 2008, Timenkov Yuri wrote:
> 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.

In KDE we have this:

macro(_SET_FANCY _var _value _comment)
   set(predefinedvalue "${_value}")

   if (NOT DEFINED ${_var})
      set(${_var} ${predefinedvalue})
   else (NOT DEFINED ${_var})
      set(${_var} "${${_var}}" CACHE PATH "${_comment}")
   endif (NOT DEFINED ${_var})
endmacro(_SET_FANCY)

_set_fancy(EXEC_INSTALL_PREFIX  "${CMAKE_INSTALL_PREFIX}"   
           "Base directory for executables and libraries")

_set_fancy(SHARE_INSTALL_PREFIX "${CMAKE_INSTALL_PREFIX}/share"
           "Base directory for files which go to share/")

_set_fancy(BIN_INSTALL_DIR      "${EXEC_INSTALL_PREFIX}/bin"
          "The install dir for executables")

_set_fancy(LIB_INSTALL_DIR      "${EXEC_INSTALL_PREFIX}/lib${LIB_SUFFIX}"
           "The install dir where libraries will be installed")
   
So if e.g. BIN_INSTALL_DIR is not yet set (which can only be from the cache, 
it is set as normal variable. As soon as the user enters BIN_INSTALL_DIR in 
the cache, this is kept and not overridden.

Is this similar to what you want ?

Alex