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.