| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
| |
|
|
|
|
|
|
|
| |
- 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.
|
|
|
|
| |
- See issue #7095.
|
|
|
|
|
|
|
| |
- Add an argument to registry read/write/delete methods to specify
a 32-bit or 64-bit view.
- Default is the bit-ness of the running program.
- See issue #7095.
|
|
|
|
|
|
| |
- Revert previous change to trust user-provided full paths.
- Instead trust them only far enough to determine the source language
but still check for existence for non-generated sources.
|
|
|
|
|
|
| |
- In cmGlobalGenerator the ExportSets ivar must be cleared at
the beginning of each Configure.
- See issue #7101.
|
|
|
|
|
| |
- Original patch from Alex.
- Modified to print only when RPATH is actually set.
|