| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
- The find_* commands now provide a HINTS option.
- The option specifies paths to be preferred over the system paths.
- Many Find* modules were using two find calls with NO_DEFAULT_PATH
to approximate the behavior, but that blocked users from overriding
things with CMAKE_PREFIX_PATH.
- This commit uses the HINTS feature to get desired behavior in
only one find command call.
|
| |
|
|
|
|
|
|
|
| |
strings for equality instead of "=="
This also matches what the man page for test says
"s1 = s2 True if the strings s1 and s2 are identical."
Alex
|
| |
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
| |
- Locating a header inside a framework often requires globbing
- Previously the glob was <dir>/*/Headers/<name>
- Now the glob is <dir>/*.framework/Headers/<name>
- This is much faster when <dir> is not really a framework dir
|
| |
|
|
|
|
|
|
|
|
|
| |
- 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.
|
| |
|
|
|
|
| |
- Create cmFindCommon::AddTrailingSlashes
- Use it in cmFindBase and cmFindPackageCommand
- Remove duplication from other find commands
|
| | |
|
| | |
|
| |
|
|
|
|
| |
- Previously the find_* commands did not normalize the search paths
- The recent refactoring enabled such normalization
- The FindBase test must also normalize before comparing paths
|
| |
|
|
|
|
| |
- 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.
|
| | |
|
| | |
|
| |
|
|
|
| |
- Patch from Matthew McCormick, slightly tweaked
- See issue #6833
|
| | |
|
| |
|
|
| |
the top level
|
| |
|
|
| |
refactoring commit.
|
| |
|
|
|
| |
Relative paths going outside the current source dir resulted in badly
placed moc source files in the build dir (or out of the build dir).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
- 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.
|
| |
|
|
| |
IDE adds some extra characters to the variable value during expansion.
|
| |
|
|
|
|
|
| |
- 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.
|
| | |
|
| |
|
|
| |
VERBATIM option.
|
| |
|
|
| |
variable replacement.
|
| | |
|
| |
|
|
|
| |
qt4-devel is installed. Finding them was required to support building
against static Qt. Changing it so they are ignored if not found.
|
| | |
|
| |
|
|
|
|
|
| |
- The rule hash should use only commands specified by the user.
- No make output (echo and progress) rules should be included.
- No outputs or dependencies need be included. The native build tool
will take care of them.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
- Option was recently added but never released.
- Custom commands no longer depend on build.make so we do
not need the option.
- Rule hashes now take care of rebuilding when rules change
so the dependency is not needed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- In CMake 2.4 custom commands would not rebuild when rules changed.
- In CMake 2.6.0 custom commands have a dependency on build.make
which causes them to rebuild when changed, but also when any
source is added or removed. This is too often.
- We cannot have a per-rule file because Windows filesystems
do not deal well with lots of small files.
- Instead we add a persistent CMakeFiles/CMakeRuleHashes.txt file
at the top of the build tree that is updated during each
CMake Generate step. It records a hash of the build rule for
each file to be built. When the hash changes the file is
removed so that it will be rebuilt.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
have worked right
|
| | |
|
| |
|
|
| |
have physical id tag or cpu cores tag.
|
| |
|
|
| |
better, bad cpu info is better than a crash
|
| | |
|
| |
|
|
| |
LogicalProcessorsPerPhysical under Linux. Some part was just wrong. Some other part missed to take the multicore value into account.
|
| |
|
|
| |
enabled. Not sure why it was disabled to start with, but I suspect I will find out. In reponse to Bill email about a ctest -S script with a function that waqs not closed. Closure was only checked for regular listfiles not other files.
|
| | |
|
| |
|
|
| |
because some folks have been doing that and 2.4 handled it
|
| | |
|
| |
|
|
| |
same name, bug# 7042
|
| | |
|
| | |
|
