[CMake] Patch: Add NO_CACHE option to find_xxx commands

[Miguel A. Figueroa-Villanueva]

On Mon, Jul 7, 2008 at 6:25 PM, Alexander Neundorf wrote:
> 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.
> [snip]
>
> Is this similar to what you want ?

Not really. Consider the following example:

# Try to find an XXX installation binary path and save it in a cached variable
find_path(XXX_EXECUTABLE_DIR
  NAMES ...
  PATHS ...
  )

# Then find or verify the existance of each component in the root dir, and
# set each XXX_YYY_EXECUTABLE variable (non-cached)
if (XXX_EXECUTABLE_DIR)
  foreach (component ${XXX_FIND_COMPONENTS})
    set(_XXX_YYY_EXECUTABLE
      ${XXX_EXECUTABLE_DIR}/${component}${CMAKE_EXECUTABLE_SUFFIX}
      )
    if (EXISTS ${_XXX_YYY_EXECUTABLE})
      set(XXX_${component}_EXECUTABLE ${_XXX_YYY_EXECUTABLE})
    else (EXISTS ${_XXX_YYY_EXECUTABLE})
      set(XXX_${component}_EXECUTABLE NOTFOUND)
    endif (EXISTS ${_XXX_YYY_EXECUTABLE})
  endforeach (component)
endif (XXX_EXECUTABLE_DIR)

I think it would be much clearer if we could write the following:

if (XXX_EXECUTABLE_DIR)
  foreach (component ${XXX_FIND_COMPONENTS})
    find_program (XXX_${component}_EXECUTABLE ${component}
      ${XXX_EXECUTABLE_DIR}
      NO_DEFAULT_PATH
      NO_CACHE
      )
  endforeach (component)
endif (XXX_EXECUTABLE_DIR)

This is a somewhat trivial example, but note that in the first example
(with the if/else) the user has to be aware of the
CMAKE_EXECUTABLE_SUFFIX. It gets more complicated when you would like
to find a library or an object that can have several NAMES, where you
would require a very complex if/else structure and knowledge of
library naming conventions in every platform, but the find_xxx
commands already handle all of this (except that they put the result
in the cache).

Now, why not have them in the cache. Well we could, but what if you
want to try a non-default version of ImageMagick? You would need to
set each component individually (which is very annoying) or come up
with logic (as I have done in FindwxWidgets) so that everytime the
XXX_EXECUTABLE_DIR changes all the XXX_YYY_EXECUTABLE variables are
reset.

I don't know if people often have the need for this feature, but I
would find it useful in several of the FindXXX.cmake modules that I
have worked with. And it is a simple thing to implement; I've already
attached a patch to the feature request.

The only drawback that I can think of is the point that Bill brought
up about the fact that the find_xxx(...NO_CACHE) would search every
time you run cmake. However, I don't think this would be a burden,
because you normally would not want to use NO_CACHE (it is only for
particular cases) and when you do you typically search in a limited
set of directories, such as done above.

Hope this clarifies things a bit.

--Miguel