[CMake] Patch: Add NO_CACHE option to find_xxx commands

[Miguel A. Figueroa-Villanueva]

On Mon, Jul 7, 2008 at 2:39 AM, 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.

Yes, the user is allowed to modify the cache variable as usual
(wxWidgets_LIB_DIR). But the idea is that by using NO_CACHE in the
find for wxWidgets_core_LIBRARY, this will make it a non-cache
variable and hence not let the user specify it manually.

The idea is that many packages have a root installation. I would like
to let the user have the flexibility to specify that, hence that
should be a cache variable. But then I don't want the user to
intervene, nor do I want to pollute the cache with many variables for
libs that I know will be in ${ROOT_DIR}/lib.

> 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 are two separate feature requests that address this problem a
bit differently (7286 and 7290).

7286: suggests adding a DEPENDS option. In this case you would have
for the example above:

find(wxWidgets_core_LIBRARY ... DEPENDS wxWidgets_LIB_DIR)

and cmake should set wxWidgets_core_LIBRARY to NOTFOUND everytime
wxWidgets_LIB_DIR is changed.

7290: suggests having a NO_CACHE option which basically makes
wxWidgets_core_LIBRARY a non-cache variable and hence removes it from
the GUI:

find(wxWidgets_core_LIBRARY ... NO_CACHE)

In both cases the burden is on the writer of the find_XXX line, not on
the user. In the second (7290), we work under the assumption that
after getting the wxWidgets_LIB_DIR we won't need help in finding
wxWidgets_core_LIBRARY from the user. In the first (7286), we still
allow the user access to change wxWidgets_core_LIBRARY after
wxWidgets_LIB_DIR is set if we can't find it or find the wrong one.

> 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.

Thanks,
--Miguel