On HP-UX machines some system libraries appear in architecture-specific
implicit linker search paths. We need to add these paths to our system
library search path. However, at the time we construct the search path
we do not know the target architecture.
A full solution requires re-organizing platform configuration files so
that the target architecture can be known when needed. Until that
happens we can avoid the problem by searching in both 32-bit and 64-bit
implicit link directories. By telling CMake that they are implicit
directories the generated link lines will never pass the paths, leaving
the linker free to find the library of the proper architecture even if
the find_library call finds the wrong one.
This adds the Modules/Platform/OpenVMS.cmake platform file for OpenVMS.
We just use Unix-like rules to work with the GNV compiler front-end.
A problem with process execution currently prevents CMake link scripts
from working, so we avoid using them.
HP-UX uses both .sl and .so as extensions for shared libraries. This
teaches CMake to recognize .so shared libraries so they are treated
properly during link dependency analysis.
This enables the --enable-auto-import linker flag on Cygwin when linking
executables. It works with the old gcc 3.x compiler and is necessary
for the new gcc 4.x compiler. See issue #9071.
Previously CTest would drop dashboard submissions at public.kitware.com
on the PublicDashboard project if there was no configuration. The
server no longer supports forwarding to cdash.org, so there is no point
in this default. Furthermore, there should be no default at all because
it could leak information about proprietary projects that are not
configured correctly.
This creates cmCTestBZR to drive CTest Update handling on bzr-based work
trees. Currently we always update to the head of the remote tracking
branch (bzr pull), so the nightly start time is ignored for Nightly
builds. A later change will address this. Patch from Tom Vercauteren.
See issue #6857.
CMakeSystemSpecificInformation.cmake into a separate file,
CMakeEclipseCDT4.cmake
-if CMAKE_EXTRA_GENERATOR is set, i.e. either CodeBlocks or KDevelop3 or
EclipseCDT4, load a matching cmake script file, which can do things specific
for this generator
- added such files for Eclipse, KDevelop and CodeBlocks, one thing they all
do is they try to find the respective IDE and store it in the
CMAKE_(KDEVELOP3|CODEBLOCKS|ECLIPSE)_EXECUTABLE variable.
This could be used by cmake-gui to open the project it just generated with
the gui (not sure this is possible with eclipse).
Alex
After extracting the tarball in a temporary directory we copy the tree
to the destination directory. The 'cmake -E copy_directory' command
does not preserve file timestamps, so we use file(COPY) instead.
The add_external_project function separates its arguments with ';'
separators, so previously no command line argument could contain one.
When specifying CMAKE_ARGS, some -D argument values may need to contain
a semicolon to form lists in the external project cache.
This adds add_external_project argument LIST_SEPARATOR to specify a list
separator string. The separator is replaced by ';' in arguments to any
command created to drive the external project. For example:
add_external_project(...
LIST_SEPARATOR ::
CMAKE_ARGS -DSOME_LIST:STRING=A::B::C
...)
passes "-DSOME_LIST:STRING=A;B;C" to CMake for the external project.
This fixes the get_configure_command_id function to not mistake
CONFIGURE_COMMAND values that run "cmake -P" or "cmake -E" for a CMake
project configuration. These values just help run scripts.
This creates function 'add_external_project_step' to centralize creation
of external project steps. Users may call it to add custom steps to
external project builds.
The add_external_project function parses its arguments and puts them in
properties of the target it creates. This factors out implementation of
the behavior for use by other functions in the module.
The patch step runs parallel to the update step since it does not make
sense to have both. Configuration of the step requires specification of
a PATCH_COMMAND argument to add_external_project.
This rewrites the keyword/argument parsing and handling in the
AddExternalProject module to use arguments more literally:
- The strict keyword-value pairing is gone in favor of keywords with
arbitrary non-keyword values. This avoids requiring users to escape
spaces and quotes in command lines.
- Customized step command lines are now specified with a single
keyword <step>_COMMAND instead of putting the arguments in a
separate entry (previously called <step>_ARGS).
- Build step custom commands now use VERBATIM mode so that arguments
are correctly escaped on the command line during builds.
This creates global property RULE_MESSAGES which can be set to disbale
per-rule progress and action reporting. On Windows, these reports may
cause a noticable delay due to the cost of starting extra processes.
This feature will allow scripted builds to avoid the cost since they do
not need detailed information anyway. This replaces the RULE_PROGRESS
property created earlier as it is more complete. See issue #8726.
This creates global property RULE_PROGRESS which can be set to disbale
per-rule progress reporting. On Windows, progress reports may cause a
noticable delay due to the cost of starting an extra process. This
feature will allow scripted builds to avoid the cost since they do not
need detailed progress anyway. See issue #8726.
its system include directories. These are catched in CMakeSystemSpecificInformation.cmake
(only with the Eclipse generator) and then written by the Eclipse generator
in the Eclipse project file. This way Eclipse can find the standard headers
(#7585)
Not sure CMakeSystemSpecificInformation.cmake is the best place to do this.
Alex
This teaches AddExternalProject to run "$(MAKE)" for build and install
steps of CMake-based external projects when using a Makefile generator.
It allows the external project to participate in a parallel make invoked
on the superproject.
This uses the get_property command to simplify property lookup in the
AddExternalProject module. It distinguishes for build and install
argument properties the cases of unset and set to empty.
This creates variable CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES to
specify implicit include directories on a per-language basis. This
replaces the previous platform-wide variable. It is necessary to
avoid explicit specification of -I/usr/include on some compilers
(such as HP aCC) because:
1.) It may break ordering among system include directories defined
internally by the compiler, thus getting wrong system headers.
2.) It tells the compiler to treat the system include directory
as a user include directory, enabling warnings in the headers.
See issue #8598.
We used to suppress generation of -I/usr/include (and on OSX also
-I/usr/local/include). This behavior seems to cause more trouble than
it's worth, so I'm removing it until someone encounters the original
problem it fixed. See issue #8598.
This defines a new CTest configuration variable CTEST_USE_LAUNCHERS.
When set to true it puts 'ctest --launch' in RULE_LAUNCH_* properties
and enables the CTest configuration option 'UseLaunchers'. Currently
this works only for Makefile generators.
This defines global, directory, and target properties
RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, and RULE_LAUNCH_CUSTOM. Their
values specify 'launcher' command lines which are prefixed to compile,
link, and custom build rules by Makefile generators.
Bill Hoffman
Brad King
Alexander Neundorf
David Cole
Clinton Stimpson
Philip Lowman
Miguel A. Figueroa-Villanueva
Christopher Harvey