This clarifies documentation of the find_* commands' PATH_SUFFIXES
option. The option adds paths with the suffixes but does not remove the
paths without the suffixes.
In cmFindBase we were searching all path suffixes appended to all paths
before considering the paths without any suffixes. Instead we should
consider each path with and without suffixes before moving to the next
path. See issue #7783.
- The short-hand forms do not document the NO_* options.
- CMake 2.4 and 2.6.0 accepted them accidentally, but also
treated the options as paths.
- Now the options are accepted but do not become paths.
- The CMAKE_PREFIX_PATH and similar variables have both
environment and CMake cache versions.
- Previously the environment value was checked before the
cache value.
- Now the cache value is favored because it is more specific.
- Hints are searched after user locations but before system locations
- The HINTS option should have paths provided by system introspection
- The PATHS option should have paths that are hard-coded guesses
- CMAKE_FIND_FRAMEWORK and CMAKE_FIND_APPBUNDLE are supposed to specify
whether to find frameworks/appbundles FIRST, LAST, ONLY, or NEVER.
- Previously this affected only the placement of CMAKE_FRAMEWORK_PATH
and CMAKE_APPBUNDLE_PATH with respect to the other path specifiers.
- Now it behaves as documented. The entire search path is inspected for
each kind of program, library, or header before trying the next kind.
- Additionally the ONLY mode is now honored for headers so that users
do not end up with a library in framework and a header from elsewhere.
- In cmFindBase when CheckCommonArgument returns true, set newStyle
- Otherwise if there are no PATHS then the ancient-style compatibility
mode is enabled and the common argument is treated as a path.
- Add each part of the search order in a separate method.
- Collect added paths in an ivar in cmFindCommon.
- Move user path storage up to cmFindCommon and share
between cmFindBase and cmFindPackageCommand.
- Expand user path registry values up in cmFindCommon
- Enables 32-/64-bit registry view for find_package
- Disables registry expansion for paths not specified
with the PATHS argument, which is not expected.
- cmFindBase should search both 32-bit and 64-bit registry views
for FIND_PROGRAM even if CMAKE_SIZEOF_VOID_P is not set.
- Needed because the variable is not available when CMAKE_MAKE_PROGRAM
is to be found.
- The target platform does not matter for finding executables
so find_program should expand to both 32-bit and 64-bit registry
values.
- See issue #7095.
- Remove CMP_0001 (no slash in target name) and restore
old CMAKE_BACKWARDS_COMPATIBILITY check for it
- Replace all checks of CMAKE_BACKWARDS_COMPATIBILITY
with cmLocalGenerator::NeedBackwardsCompatibility calls
- Create new CMP_0001 to determine whether or not
CMAKE_BACKWARDS_COMPATIBILITY is used.
(old = use, new = ignore)
- Show CMAKE_BACKWARDS_COMPATIBILITY in cache only when
CMP_0001 is set to OLD or WARN
- Update documentation of cmake_policy and cmake_minimum_required
to indicate their relationship and the 2.4 version boundary
- When no cmake policy version is set in top level makefile
implicitly call cmake_policy(VERSION 2.4) which restores
CMAKE_BACKWARDS_COMPATIBILITY and other 2.4 compatibility
- Fix tests MakeClean and Preprocess to call
cmake_policy(VERSION 2.6) because they depend on new policies
- Use CMAKE_PREFIX_PATH and CMAKE_SYSTEM_PREFIX_PATH among other means
to locate package configuration files.
- Create cmFindCommon as base for cmFindBase and cmFindPackageCommand
- Move common functionality up to cmFindCommon
- Improve documentation of FIND_* commands.
- Fix FIND_* commands to not add framework/app paths in wrong place.
CMAKE_FIND_PREFIX_PATH is both an environment variable and a cmake variable,
which is a list of base directories where FIND_PATH, FIND_FILE, FIND_PROGRAM
and FIND_LIBRARY will search in the respective subdirectories
Alex
-add a RESULT_VARIABLE to INCLUDE()
-add CMAKE_TOOLCHAIN_FILE for specifiying your (potentially crosscompiling) toolchain
-have TRY_RUN() complain if you try to use it in crosscompiling mode (which were compiled but cannot run on this system)
-use CMAKE_EXECUTABLE_SUFFIX in TRY_RUN(), probably TRY_RUN won't be able to
run the executables if they have a different suffix because they are
probably crosscompiled, but nevertheless it should be able to find them
-make several cmake variables presettable by the user: CMAKE_C/CXX_COMPILER, CMAKE_C/CXX_OUTPUT_EXTENSION, CMAKE_SYSTEM_NAME, CMAKE_SYSTEM_INFO_FILE
-support prefix for GNU toolchains (arm-elf-gcc, arm-elf-ar, arm-elf-strip etc.)
-move ranlib on OSX from the file command to a command in executed in cmake_install.cmake
-add support for stripping during install in cmake_install.cmake
-split out cl.cmake from Windows-cl.cmake, first (very incomplete) step to support MS crosscompiling tools
-remove stdio.h from the simple C program which checks if the compiler works, since this may not exist for some embedded platforms
-create a new CMakeFindBinUtils.cmake which collects the search fro ar, ranlib, strip, ld, link, install_name_tool and other tools like these
-add support for CMAKE_FIND_ROOT_PATH for all FIND_XXX commands, which is a
list of directories which will be prepended to all search directories, right
now as a cmake variable, turning it into a global cmake property may need
some more work
-remove cmTestTestHandler::TryExecutable(), it's unused
-split cmFileCommand::HandleInstall() into slightly smaller functions
Alex
Bill Hoffman
Brad King
Alexander Neundorf
Amitha Perera
Ken Martin