Custom command dependencies that are not full paths or targets may also
match source files. When one does, the full information about the
source file's location and name may be used. This fixes the case when a
custom commands depends by relative path on a source file generated by
another custom command specifying its output by relative path.
A name with an ambiguous extension may only match an unambiguous name
that is extended by one of the fixed set of extensions tried when
finding the source file on disk. This rule makes matching of source
files with ambiguous extensions much less aggressive but still
sufficient.
When generating RPATH entries on the link line using a repeated linker
flag (-R ... -R ... style) do not convert individual entries to a full
path. We need to preserve what the user requested.
When generating escape sequences for the native build tool do not put in
Makefile escapes for paths generated into link scripts. This fixes
putting "$ORIGIN" into the RPATH, and probably some other subtle
problems.
Creation of archive libraries with the unix 'ar' tool should be done
incrementally when the number of object files is large. This avoids
problems with the command line getting too many arguments.
When attempting to load the RPATH out of a non-ELF file cmELF would
crash because the check for a valid file was done with in correct
operator precedence. See bug#7392.
For historical reasons we still support naming of source files without
their extension. Sources without known extensions are located on disk
by iterating through a fixed set of possible extensions. We now want
users to always specify the extension, so the fixed set will not be
expanded and is preserved for compatibility with older projects.
This change adds recognition of extensions of all enabled languages to
avoid checking the disk for files whose extensions are unambiguous but
not in the original fixed set.
In CMake 2.4 the generated link line for a target always preserved the
originally specified libraries in their original order. Dependencies
were satisfied by inserting extra libraries into the line, though it had
some bugs. In CMake 2.6.0 we preserved only the items on the link line
that are not known to be shared libraries. This reduced excess
libraries on the link line. However, since we link to system libraries
(such as /usr/lib/libm.so) by asking the linker to search (-lm), some
linkers secretly replace the library with a static library in another
implicit search directory (developers can override this by using an
imported target to force linking by full path). When this happens the
order still matters.
To avoid this and other potential subtle issues this commit restores
preservation of all non-target items and static library targets. This
will create cases of unnecessary, duplicate shared libraries on the link
line if the user specifies them, but at least it will work. In the
future we can attempt a more advanced analysis to safely remove
duplicate shared libraries from the link line.
We preserve the order and multiplicity of libraries directly linked by a
target as specified by the user. Items known to be shared libraries may
be safely skipped because order preservation is only needed for static
libraries. However, CMake 2.4 did not skip shared libs, so we do the
same when in 2.4 compatibility mode.
We never explicitly specify system library directories in linker or
runtime search paths. Furthermore, libraries in these directories are
always linked by asking the linker to search for them. We need to
generate a warning when explicitly specified search directories contain
files that may hide the system libraries during the search.
This change introduces policy CMP0008 to decide how to treat full path
libraries that do not appear to be valid library file names. Such
libraries worked by accident in the VS IDE and Xcode generators with
CMake 2.4 and below. We support them in CMake 2.6 by introducing this
policy. See policy documentation added by this change for details.
Sometimes we ask the linker to search for a library for which the path
is known but for some reason cannot be specified by full path. In these
cases do not include the library in CMP0003 warnings because we know the
extra paths are not needed for it.
- This case worked accidentally in CMake 2.4, though not in Makefiles.
- Some projects build only with the VS IDE on windows and have this
mistake.
- Support them when 2.4 compatibility is enabled by adding the extension.
CMAKE[_SYSTEM]_(LIBRARY|PROGRAM|INCLUDE|PREFIX)_PATH variables
-moved CMAKE_CROSSCOMPILING from "Variables that modify behaviour" to
"variables that Provide Information", since it should be used only for
testing whether we are currently in cross compiling mode, not for switching
between the modes.
Alex
- The source-file signature of try_compile looks up the language
of the source file using the extension-to-language map so that
it knows what language to enable in the generated project.
- This map needs to be filled before loading a file specified by
CMAKE_USER_MAKE_RULES_OVERRIDE
CMAKE_USER_MAKE_RULES_OVERRIDE_<LANG>
so that the user file may call the try_compile() source-file
signature.
- It must still be re-filled after loading CMake<LANG>Information.cmake
in case the compiler- or platform-specific files added anything.
- See bug #7340.
Details:
==========
- New cpack_add_component, cpack_add_component_group, and
cpack_add_install_type "commands" defined as macros in the CPack
module.
- Documentation for all of the variables and commands in the CPack module.
- Added get_cmake_property(... COMPONENTS) to CMake to ask for the
names of all components. Used in the CPack module to automatically
build component-based installers. (Set CPACK_MONOLITHIC_INSTALL to
turn off component-based installation).
- A group can declare its PARENT_GROUP, to build an arbitrary
hierarchy of groups.
- New CPack command cpack_configure_downloads, which creates an
installer that downloads only the selected components on-the-fly.
Those components marked DOWNLOADED will be separate packages
downloaded on-the-fly (or, all packages can be marked as such with the
ALL option to cpack_configure_downloads). Individual components are
compressed with ZIP at installer-creation time and
downloaded/uncompressed by the installer as needed. This feature is
only available on Windows with NSIS at the moment.
- NSIS installers can install themselves and enable the "Change"
button in Add/Remove programs, allowing users to go back and install
or remove components. This can be disabled through
cpack_configure_downloads, because it's only really useful is most of
the application's functionality is in downloaded components.
- Bug fix: automatically install everything whose COMPONENT was not
specified (it's a hidden, required group)
- Bug fix: fixed removal of components when re-running the NSIS
installer and unchecking components
- Bug fix: NSIS installers now only install/remove the minimal
number of files when re-run to update the installation (or by clicking
"Change" in Add/Remove programs)
- The Info.plist file in app bundles should not be built.
- User-specified files such as foo.txt should not be built.
- Only files with a recognized language should be built,
just as in the Makefiles generators.
- See bug #7277.
- We used to always put LIBRARY_OUTPUT_PATH and EXECUTABLE_OUTPUT_PATH
in the cache if the project did not.
- In CMake 2.6 these variables should no longer be used.
- Now add them only if CMAKE_BACKWARDS_COMPATIBILITY is also cached.
- This happens only when CMP0001 is set to OLD or WARN or if
the user or project sets it. In any case compatibility is needed.
- Reported by Miguel A. Figueroa-Villanueva and Philip Lowman.
- Generated Xcode projects for application bundles list the
CMake-generated Info.plist input file as a resource.
- The location of the input file was moved by a previous commit,
but the reference to it as a resource file was not updated.
- This change moves the file to CMakeFiles/<tgt>.dir/Info.plist
to give it a more intuitive name in the Xcode project.
- We also update the reference to point at the correct location.
- See bug #7277.
- The Xcode generator creates one Info.plist input file which is
converted at build time by Xcode and placed in the final bundle.
- The <CONFIG>_OUTPUT_NAME target property can place different content
for the exe name in Info.plist on a per-configuration basis.
- Instead of generating a per-config Info.plist input file just let
Xcode put the name in at build time using the $(EXECUTABLE_NAME) var.
- The property tracks the value formed by add_definitions
and remove_definitions command invocations.
- The string should be maintained for use in returning for the
DEFINITIONS property value.
- It is no longer used for any other purpose.
- The DEFINITIONS property was recently documented as deprecated.
- See bug #7239.
- Fix documentation of get_directory_property command.
- Convert its list of computed directory properties to be
defined/documented directory properties.
ENH: -if no compiler has been found, don't test it, and also remove the compiler
information file again. This makes optionally enabling a language work
better.
Alex
- 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
- 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.
- 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 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.
- 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.
- 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.
- Create MACOSX_BUNDLE_INFO_PLIST target property to specify template.
- Look for MacOSXBundleInfo.plist.in in CMAKE_MODULE_PATH by default.
- See issue #6983.
the generator on the first configure. It either ask for a toolchain file
or asks for all the information a toolchain file might contain.
Also added option for setting non-default compilers if not cross compiling.
Fixes#6849.
Also a bit of code cleanup and re-organizing.
- Tells CMake about the KWSYS_HEADER macro.
- Enables implicit dependencies of private source files.
- When a CMake new enough to support the property is required
the "#if 0" hack can be removed from the source files.
- Allows make rules to be created with no dependencies.
- Such rules will not re-run even if the commands themselves change.
- Useful to create rules that run only if the output is missing.
-generate and install the policy documentation files
-generate and install the docbook files for cmake, ctest, cpack, ccmake (cmake-gui not yet ?)
Alex
- Previously this was done implicitly by the check for a target
link language which checked all source full paths.
- The recent change to support computing a link language without
finding all the source files skipped the implicit check.
- This change adds an explicit check to find all source files.
the argument after -Wno-dev was skipped, which happened to be the source
directory, and so the current working directory was assumed as source
directory, although it was the build directory (maybe this didn't have an
effect if there was already a CMakeCache.txt in the build dir)
Alex
- Previously all links started in 'command_' which led to conflicts
and was confusing for non-command items.
- Use a per-section name that is meaningful to humans.
- Fix link id names to be valid HTML.
- CMake 1.8 and below did not do the check but could get in
infinite loops due to the local generate step.
- CMake 2.0 added the check but failed to perform it in directories
with no targets (see bug #678).
- CMake 2.2 removed the local generate which fixed the problem but
did not remove the check.
- Between CMake 2.4 and 2.6.0rc6 the check was fixed to work even
when no targets appear in a directory (see bug #6923).
- Bottom line: the check is no longer needed.
to help with debugging later on. The same should be done in the import
target files (but I didn't have time to do it yet).
STYLE: fix line length in cmListFileCache.cxx
Alex
- If new RPATH is empty then remove the entry completely
- Preserve file modification time so installation is not repeated
- If installed file already exists remove it if its RPATH
does not match that expected
- Place the built library in foo.framework/Versions/A/foo
- Do not create unused content symlinks (like PrivateHeaders)
- Do not use VERSION/SOVERSION properties for frameworks
- Make cmTarget::GetDirectory return by value
- Remove the foo.framework part from cmTarget::GetDirectory
- Correct install_name construction and conversion on install
- Fix MACOSX_PACKAGE_LOCATION under Xcode to use the
Versions/<version> directory for frameworks
- Update the Framework test to try these things
- Message for missing cmake_minimum_required is not issued
until the end of processing the top CMakeLists.txt file
- During processing a cmake_policy command may set behavior
- OLD behavior is to silently ignore the problem
- NEW behavior is to issue an error instead of a warning
- CMake 2.4 added link directories for targets linked
in the optimized configuration even when building debug
- Old behavior for policy CMP0003 must account for this
RUNTIME, ARCHIVE, LIBRARY, etc.) arguments are given.
If the component of a part of a target is queried, return the specific one,
if a specific one hasn't been set, return the generic one, if that hasn't
been set, return "Unspecified".
Alex
- In cmake_minimum_required do not set policy version if current
CMake is too old
- In cmPolicies::ApplyPolicyVersion report error if version is too
new or cannot be parsed
- Give example code to avoid the warning
- Make explanation more consise
- Explicitly state this is for compatibility
- Issue the warning for at most one target
- This will help projects support multiple CMake versions.
- In order to set a policy when using a newer CMake but still
working with an older CMake one may write
if(POLICY CMP1234)
cmake_policy(SET CMP1234 NEW)
endif(POLICY CMP1234)
- Note that since CMake 2.4 does not have if(POLICY) supporting
it will also require using "if(COMMAND cmake_policy)"
- Update policy CMP0000 to require use of the command
cmake_minimum_required and not cmake_policy
so there is only one way to avoid it.
- Explicitly specify the line users should add.
- Reference policy CMP0000 only at the end.
- Fix policy CMP0000 documentation to not suggest
use of the cmake_policy command.
- Add a paragraph introducing the policy mechanism
- Explicitly introduce the CMP<NNNN>, OLD, and NEW notation
- Note that setting policies by CMake version is preferred
- Fix SET signature to use CMP<NNNN> notation
- Add more details about the policy stack
- Targets built in the tree now add compatibility paths too
- The warning message's first list includes at most one item
for each unique compatibility path
- Clarified error message further
- Policy is WARN by default so projects will build
as they did in 2.4 without user intervention
- Remove CMAKE_LINK_OLD_PATHS variable since it was
never in a release and the policy supercedes it
- Report target creation backtrace in warning message
since policy should be set by that point
- Add cmListFileBacktrace to record stack traces
- Move main IssueMessage method to the cmake class instance
(make the backtrace an explicit argument)
- Change cmMakefile::IssueMessage to construct a backtrace
and call the cmake instance version
- Record a backtrace at the point a target is created
(useful later for messages issued by generators)
- ZERO_CHECK should check all stamps in case
of parallel build (fixes complex test failure)
- ZERO_CHECK should not appear when
CMAKE_SUPPRESS_REGENERATION is on (fixes bug 6490)
- 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
Brad King
David Cole
Bill Hoffman
Alexander Neundorf
Clinton Stimpson
Ken Martin
Francois Bertel
Mathieu Malaterre
Bill Lorensen
Jeffrey Baumes
Sebastien Barre