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.
Brad King
Bill Hoffman
Alexander Neundorf
David Cole