Which search paths are disabled by specifying NO_DEFAULT_PATH in find_xxx commands?

Code
1

Hello, CMake Team.

From the content of the CMake documentation, it is known:

For the find_xxx family of commands, the search is generally conducted in the following order:

  1. paths in <PackageName>_ROOT cache/environment variables.
  2. paths in CMake-specific cache variables.
  3. paths in CMake-specific environment variables.
  4. paths in the HINTS option.
  5. paths in standard system environment variables (PATH env).
  6. paths in CMake variables defined in Platform files.
  7. paths in the PATHS option.

However, what confuses me is:

  1. Firstly, according to the description in the find_program documentation, if NO_DEFAULT_PATH is specified, then find_program will not search any of the additional paths specified above.

    If NO_DEFAULT_PATH is specified, then no additional paths are added to the search. If NO_DEFAULT_PATH is not specified, the search process is as follows:

  2. However, from the content of the FindOpenSSL.cmake and the examples in the find_program documentation, it seems that NO_DEFAULT_PATH does not affect the additional paths specified in the PATHS and HINTS options.

    find_program (<VAR> NAMES name PATHS paths... NO_DEFAULT_PATH)
find_program (<VAR> NAMES name)

Therefore, I would like to confirm:

Which search paths are disabled by specifying NO_DEFAULT_PATH in find_xxx commands?

2

If NO_DEFAULT_PATH is specified, only
HINTS, PATHS, which Specify directories to search in addition to the default locations,
and ENV var sub-option, which reads paths from a system environment variable
are used.

1 Like
3

Hello, CMake Team.

I found that the description of NO_DEFAULT_PATH in find_package manual:

If NO_DEFAULT_PATH is specified all NO_* options are enabled.

is more suitable than the ones in other find_xxx manuals:

If NO_DEFAULT_PATH is specified, then no additional paths are added to the search.

How about unifying the description of NO_DEFAULT_PATH in other find_xxx manuals to match that of find_package?

Otherwise, this could lead to confusion.

4

That sounds good to me; do you mind making an MR? If not, an issue would help to track this better.

5

I’ve created an issue to track my suggestion:

https://gitlab.kitware.com/cmake/cmake/-/issues/25687