The flag "-_this_is_not_a_flag_" was not rejected by GCC 4.0 on older
Mac OS X. We now use "---_this_is_not_a_flag_" instead, which will
hopefully be rejected by all compilers.
The CMake.File test runs several scripts through "cmake -P" and checks
the output and result against known good values. This commit factors
out the checking code into a separate CMakeCheckTest module. The module
may be used by new tests.
This commit teaches the FunctionTest to check variable scope behavior
when a subdirectory is added inside a function call. Any PARENT_SCOPE
sets in the subdirectory should affect only the function scope which
called add_subdirectory and not its parent scope.
CMake now looks for a Fortran compiler matching any C or C++ compiler
already enabled. We test this by enabling C and C++ first in the
Fortran test, which is what user projects will likely do.
Visual Studio 10 uses MSBuild to drive the build. Custom commands
appear in MSBuild files inside CustomBuild elements, which appear inside
ItemGroup elements. The Outputs and AdditionalInputs elements of each
CustomBuild element are evaluated according to timestamps on disk.
MSBuild does not use inputs/outputs to order CustomBuild steps within a
single ItemGroup or across multiple ItemGroup elements. Instead we must
put only unrelated CustomBuild elements in a single ItemGroup and order
the item groups from top to bottom using a topological order of the
custom command dependency graph.
This fixes CustomCommand and ExternalProject test failures, so we remove
the expectation of these failures.
Part of this test does "git pull" on a dirty work tree. We need to make
sure that 'branch.master.rebase' is false for the test repository.
Otherwise if it is true in the user configuration then pull will refuse
to rebase and the test will fail.
We teach the FindPackageTest to build a sample project that stores its
build tree in the user package registry using export(PACKAGE), and then
find it with find_package.
We test that LINK_INTERFACE_MULTIPLICITY propagates through export() and
install(EXPORT) into dependent projects. A simple cycle of two archives
that need to be scanned three times ensures that the importing project
uses the multiplicity correctly.
This function builds a simple test project using a combination of
Fortran and C (and optionally C++) to verify that the compilers are
compatible. The idea is to help projects report very early to users
that the compilers specified cannot mix languages.
This teaches the 'testing' test to try generator expressions in
arguments to add_test(NAME). This test case mimics a common use-case of
passing executables to test driver scripts. We excercise the syntax for
per-configuration target file names.
This is a new FortranCInterface.cmake module to replace the previous
prototype. All module support files lie in a FortranCInterface
directory next to it.
This module uses a new approach to detect Fortran symbol mangling. We
build a single test project which defines symbols in a Fortran library
(one per object-file) and calls them from a Fortran executable. The
executable links to a C library which defines symbols encoding all known
manglings (one per object-file). The C library falls back to the
Fortran library for symbols it cannot provide. Therefore the executable
will always link, but prefers the C-implemented symbols when they match.
These symbols store string literals of the form INFO:symbol[<name>] so
we can parse them out of the executable.
This module also provides a simpler interface. It always detects the
mangling as soon as it is included. A single macro is provided to
generate mangling macros and optionally pre-mangled symbols.
The try_compile command builds the cmTryCompileExec executable using the
cmTryCompileExec/fast target with Makefile generators in order to save
time since dependencies are not needed. However, in project mode the
command builds an entire source tree that may have dependencies.
Therefore we can use the /fast target approach only in one-source mode.
Previously the Fortran test created a single executable containing C,
C++, and Fortran sources. This commit divides the executable into three
libraries corresponding to each language, and two executables testing
Fortran/C only and Fortran/C/C++ together. The result tests more
combinations of using the languages together, and that language
requirements propagate through linking.
When building an entire source tree with try_compile instead of just a
single source file, it is possible that the CMakeLists.txt file in the
try-compiled project invokes try_compile. This commit fixes propagation
of language-initialization results from the outer-most project into any
number of try-compile levels.
The try_compile command project mode builds an entire source tree
instead of one source file. It uses an existing CMakeLists.txt file in
the given source tree instead of generating one. This commit creates a
test for the mode in the TryCompile test.
This adds sample linker invocation lines for the Intel compiler on
Linux. In particular, this exercises the case when "ld" appears without
a full path.
The Sun Fortran compiler passes -zallextract and -zdefaultextract to the
linker so that all objects from one of its archives are included in the
link. This teaches the implicit options parser to recognize the flags.
We need to pass them explicitly on C++ link lines when Fortran code is
linked.
This extends the Fortran-to-C interface test to add a C++ source file.
The executable can only link with the C++ linker and with the proper
Fortran runtime libraries. These libraries should be detected by CMake
automatically, so this tests verifies the detection functionality.
This hack was created to help the Fortran test executables link to the
implicit C libraries added by BullsEye. Now that implicit libraries
from all languages are detected and included automatically the hack is
no longer needed.
This teaches the SystemInformation test to report the CMake log files
CMakeOutput.log and CMakeError.log from the CMake build tree and from
the SystemInformation test build tree. These logs may help diagnose
dashboard problems remotely.
This extends the Fortran/C interface test to require that the executable
link to the fortran language runtime libraries. We must verify that the
proper linker is chosen.
The commit "Avoid case change in ImplicitLinkInfo test" did not change
all of the paths to mingw, so some case change still occurs. This
changes more of them.
Since "get_filename_component(... ABSOLUTE)" retrieves the actual case
for existing paths on windows, we need to use an obscure path for mingw.
Otherwise the test can fail just because the case of the paths changes.
This tests the internal CMakeParseImplicitLinkInfo.cmake module to
ensure that implicit link information is extracted correctly. The test
contains many manually verified examples from a variety of systems.
This teaches CMake to detect implicit link information for C, C++, and
Fortran compilers. We detect the implicit linker search directories and
implicit linker options for UNIX-like environments using verbose output
from compiler front-ends. We store results in new variables called
CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES
CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES
The implicit libraries can contain linker flags as well as library
names.
The command "set(... PARENT_SCOPE)" should never affect the calling
scope. This improves the Function test to check that such calls in a
subdirectory scope affect the parent but not the child.
When this test was renamed from DumpInformation to SystemInformation the
configured header that points the dump executable to the directory
containing information files was broken. No information has been dumped
by this test for 2 years! This fixes it.
The ExportImport test drives its Export and Import projects using the
same compiler and flags. This converts the ctest --build-and-test
command lines to use an initial cache file instead of passing all
settings on the command line.
We need a shorter command line to pass through VS 6 on Win98.
This approach reduces duplicate code anyway.
cmCTestScriptHandler, but have it load the new script CTestScriptMode.cmake
-> that makes it more flexible, also add a simple test that the system name
has been determined correctly
Alex
This extends the ExportImport test. The Export project creates a C++
static library and exports it. Then the Import project links the
library into a C executable. On most platforms the executable will link
only if the C++ linker is chosen correctly.
This test creates a C executable that links to a C++ static library. On
most platforms the executable will not link unless the C++ linker is
chosen correctly.
This creates cmCTestHG to drive CTest Update handling on hg-based work
trees. Currently we always update to the head of the remote tracking
branch (hg pull), so the nightly start time is ignored for Nightly
builds. A later change will address this.
See issue #7879. Patch from Emmanuel Christophe. I modified the patch
slightly for code style, to finish up some parsing details, and to fix
the test.
This creates new module ExternalProject.cmake to replace the prototype
AddExternalProject.cmake module. The interface is more refined, more
flexible, and better documented than the prototype.
This also converts the ExternalProject test to use the new module. The
old module will be removed (it was never in a CMake release) after
projects using it have been converted to the new module.
This test requires a long time on slower machines, so we need to extend
its timeout. It is an important test, so it does not fall under the
CMAKE_RUN_LONG_TESTS option. In the future we should try to shorten the
test by building simpler external projects.
The test needs to create a cvs repository with 'cvs init', but the CVSNT
client on Windows needs 'cvs init -n' to avoid administrator access.
Previously we required users to explicitly enable CTEST_TEST_UPDATE_CVS
to activate the test on Windows.
This teaches the test to use the '-n' option when necessary. Now we can
enable the test in all cases except when trying to use a cygwin cvs.exe
without cygwin paths.
If an executable marks symbols with __declspec(dllexport) then VS
creates an import library for it. However, it forgets to create the
directory that will contain the import library if it is different from
the location of the executable. We work around this VS bug by creating
a pre-build event on the executable target to make the directory.
The BZR xml output plugin can use some encodings that are not recognized
by expat, which leads to "Error parsing bzr log xml: unknown encoding".
This works around the problem by giving expat a mapping, and adds a
test. Patch from Tom Vercauteren. See issue #6857.
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.
CMake directory removal code cannot remove content from read-only
directories (a separate bug which will be fixed). Therefore we should
not create them in the StringFileTest. This tweaks the file(COPY) call
to test not giving OWNER_WRITE to files rather than directories.
This property was left from before CMake always linked using full path
library names for targets it builds. In order to safely link with
"-lfoo" we needed to avoid having both shared and static libraries in
the build tree for targets that switch on BUILD_SHARED_LIBS. This meant
cleaning both shared and static names before creating the library, which
led to the creation of CLEAN_DIRECT_OUTPUT to disable the behavior.
Now that we always link with a full path we do not need to clean old
library names left from an alternate setting of BUILD_SHARED_LIBS. This
change removes the CLEAN_DIRECT_OUTPUT property and instead uses its
behavior always. It removes some complexity from cmTarget internally.
This creates target properties ARCHIVE_OUTPUT_NAME, LIBRARY_OUTPUT_NAME,
and RUNTIME_OUTPUT_NAME, and per-configuration equivalent properties
ARCHIVE_OUTPUT_NAME_<CONFIG>, LIBRARY_OUTPUT_NAME_<CONFIG>, and
RUNTIME_OUTPUT_NAME_<CONFIG>. They allow specification of target output
file names on a per-type, per-configuration basis. For example, a .dll
and its .lib import library may have different base names.
For consistency and to avoid ambiguity, the old <CONFIG>_OUTPUT_NAME
property is now also available as OUTPUT_NAME_<CONFIG>.
See issue #8920.
The file(INSTALL) command has long been undocumented and used only to
implement install() scripts. We now document it and provide a similar
file(COPY) signature which is useful in general-purpose scripts. It
provides the capabilities of install(DIRECTORY) and install(FILES) but
operates immediately instead of contributing to install scripts.
This extends the Preprocessor test to put spaces in the value of a
definition that is not a quoted string. In particular this tests that
VS6 supports values with spaces if they do not have '"', '$', or ';'.
See issue #8779.
Previously we rejected all preprocessor definition values containing
spaces for the VS6 IDE generator. In fact VS6 does support spaces but
not in combination with '"', '$', or ';', and only if we use the sytnax
'-DNAME="value with spaces"' instead of '-D"NAME=value with spaces"'.
Now we support all definition values that do not have one of these
invalid pairs. See issue #8779.
This creates cmCTestGIT to drive CTest Update handling on git-based work
trees. Currently we always update to the head of the remote tracking
branch (git pull), so the nightly start time is ignored for Nightly
builds. A later change will address this. See issue #6994.
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.
Linking to a Windows shared library (.dll) requires only its import
library (.lib). This teaches CMake to recognize SHARED IMPORTED library
targets that set only IMPORTED_IMPLIB and not IMPORTED_LOCATION.
CVS clients recognize file modifications only if a file's timestamp is
newer than its CVS/Entries line. This fixes intermittent failure of the
test on filesystems with low timestamp resolution by delaying before
creating a local modification.
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 value of CMAKE_CURRENT_LIST_FILE is supposed to be the list file
currently being executed. Before macros were introduced this was always
the context of the argument referencing the variable.
Our original implementation of macros replaced the context of command
arguments inside the macro with that of the arguments of the calling
context. This worked recursively, but only worked when macros had at
least one argument. Furthermore, it caused parsing errors of the
arguments to report the wrong location (calling context instead of line
with error).
The commit "Improve context for errors in macros" fixed the latter bug
by keeping the lexical context of command arguments in macros. It broke
evaluation of CMAKE_CURRENT_LIST_FILE because the calling context was no
longer preserved in the argument referencing the variable. However,
since our list file processing now maintains the proper value of
CMAKE_CURRENT_LIST_FILE with dynamic scope we no longer need the context
of the argument and can just evaluate the variable normally.
The add_definitions() command and COMPILE_DEFINITIONS dir/tgt/src
properties support preprocessor definitions with values. Previously
values were not supported in the VS6 generator even though the native
tool supports them. It is only values with spaces that VS6 does not
support. This enables support and instead complains only for values
with spaces. See issue #8779.
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 a new mode of the foreach command which allows precise
iteration even over empty elements. This mode may be safely extended
with more keyword arguments in the future. The cost now is possibly
breaking scripts that iterate over a list of items beginning with 'IN',
but there is no other way to extend the syntax in a readable way.
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.
This creates command mode add_test(NAME ...). This signature is
extensible with more keyword arguments later. The main purpose is to
enable automatic replacement of target names with built target file
locations. A side effect of this feature is support for tests that only
run under specific configurations.
This adds the CACHE option to set_property and get_property commands.
This allows full control over cache entry information, so advanced users
can tweak their project cache as desired. The set_property command
allows only pre-defined CACHE properties to be set since others would
not persist anyway.
This moves the version numbers into an isolated configured header so
that not all of CMake needs to rebuild when the version changes.
Previously we had spaces, dashes and/or the word 'patch' randomly chosen
before the patch number. Now we always report version numbers in the
traditional format "<major>.<minor>.<patch>[-rc<rc>]".
We still use odd minor numbers for development versions. Now we also
use the CCYYMMDD date as the patch number of development versions, thus
allowing tests for exact CMake versions.
This cleans up the 'cmake --build' command-line interface:
- Rename --clean to --clean-first to better describe it.
- Replace --extra-options with a -- separator to simplify passing of
multiple native build tool options.
- Document the options in the main CMake man page description of the
--build option, and shares this with the usage message.
- Require --build to be the first argument when present.
- Move implementation into cmakemain where it belongs.
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 adds the OPTIONAL option to the install(DIRECTORY) command. It
tells the installation rule that it is not an error if the source
directory does not exist. See issue #8394.
This patch from Philip Lowman creates a REALPATH mode in the
get_filename_component command. It is like ABSOLUTE, but will also
resolve symlinks (which ABSOLUTE once did but was broken long ago).
See issue #8423.
The patch used to fix this bug used SystemTools::GetRealPath which works
only for existing files. It broke the case of using the command
get_filename_component for a non-existing file. Also, it changed
long-standing behavior in a possibly incompatible way even for existing
files. This reverts the original fix and instead updates the
documentation to be consistent with the behavior.
Isolation of policy changes inside scripts is important for protecting
the including context. This teaches include() and find_package() to
imply a cmake_policy(PUSH) and cmake_policy(POP) around the scripts they
load, with a NO_POLICY_SCOPE option to disable the behavior. This also
creates CMake Policy CMP0011 to provide compatibility. See issue #8192.
This teaches functions and macros to use policies recorded at creation
time when they are invoked. It restores the policies as a weak policy
stack entry so that any policies set by a function escape to its caller
as before.
Recently we taught find_package to re-find a package if its
<package>_DIR result variable was set to a location not containing the
package (instead of reporting an error as before). This tests the
feature.
The new 'testing' test behavior of actually running the tests generated
by the project still fails when the test script guesses the Debug
configuration but the CMake build tree was only built Release. The
inner ctest needs to find the ctest executable but is given the wrong
configuration.
The recent change of the 'testing' test to actually drive the tests
within it does not work on Windows with released CMakes 2.6.2 and lower
if no configuration is given to ctest with a -C option. This works
around the problem by detecting the case and changing the empty
configuration to Debug.
On Windows the KWSys System package generates escapes for command-line
arguments. This fix enables quoting of the empty string as an argument.
This also adds a test to pass an empty argument to a custom command.
The 'testing' CMake test builds a project that uses add_test. This
strengthens the test to actually run CTest on the project build tree
after building it.
We now search in
<prefix>/<name>*/
<prefix>/<name>*/(cmake|CMake)
when looking for package configuration files. This is useful on Windows
since the Program Files folder is in CMAKE_SYSTEM_PREFIX_PATH. These
paths are the Windows equivalent to the Apple convention application and
framework paths we already search. See issue #8264.
The $ENV{VAR} syntax permits access to environment variables. This
teaches CMake to recognize most characters in the VAR name since some
environments may have variables with non-C-identifier characters.
The previous change to test finding in lib/cmake/<name>* weakened the
versioned find tests. Since the lib/cmake paths are searched before
lib/<name>* paths the previous change skipped requiring the command to
ignore zot-3.0 when finding zot-3.1. This change restores that and adds
zot-4.0 to test the lib/cmake path.
This teaches find_package to search
<prefix>/(share|lib)/cmake/<name>*/
for package configuration files. Packages that do not already have
files in a <prefix>/lib/<name>* directory can use this location to avoid
cluttering the lib directory.
When CMake is built by CMake 2.4 or lower the FindCVS module is not
available. In that case we activiate CTest.UpdateCVS by searching for
the cvs command directly.
This creates new tests "CTest.UpdateSVN" and "CTest.UpdateCVS". They
test that the Update.xml produced by CTest for a version-controlled
project contains entries for files added, changed, and removed.
This adds a SOURCES option to ADD_CUSTOM_TARGET, enabling users to
specify extra sources for inclusion in the target. Such sources may not
build, but will show up in the IDE project files for convenient editing.
See issue #5848.
Recently we taught find_package that the NO_MODULE option is implied
when it is recursively invoked in a find-module. This behavior may be
confusing because two identical calls may enter different modes
depending on context. It also disallows the possibility that one
find-module defers to another find-module by changing CMAKE_MODULE_PATH
and recursively invoking find_package. This change reverts the feature.
Package version test files may now declare that they are unsuitable for
use with the project testing them. This is important when the version
being tested does not provide a compatible ABI with the project target
environment.
These changes teach find_package to behave nicely when invoked
recursively inside a find-module for the same package. The module will
never be recursively loaded again. Version arguments are automatically
forwarded.
Provide VERSION_LESS, VERSION_EQUAL, and VERSION_GREATER operators in
the if() command. This simplifies component-wise comparison of version
numbers in the form "major[.minor[.patch[.tweak]]]".
Make the number of version components specified explicitly available.
Set variables for unspecified version components to "0" instead of
leaving them unset. This simplifies version number handling for find-
and config-modules. Also support a fourth "tweak" version component
since some packages use them.
This introduces the unset() command to make it easy to unset CMake
variables, environment variables, and CMake cache variables. Previously
it was not even possible to unset ENV or CACHE variables (as in
completely remove them). Changes based on patch from Philip Lowman.
See issue #7507.
Some native build tools, particularly those for cross compiling, may
have a limit on the length of the full path to an object file name that
is lower than the platform otherwise supports. This change allows the
limit to be set by the project toolchain file through the variable
CMAKE_OBJECT_PATH_MAX.
It is useful to be able to test if a target has been created. Often
targets are created only inside conditions. Rather than storing the
result of the condition manually for testing by other parts of the
project, it is much easier for the other parts to just test for the
target's existence. This will also be useful when find-modules start
reporting results with IMPORTED targets and projects want to test if a
certain target is available.
We frequently need to wipe out all the CMake test build directories in
order to run tests from scratch. This change adds a test_clean custom
target to remove all these directories for out-of-source builds.
When creating an IMPORTED target for a library that has been found on
disk, it may not be known whether the library is STATIC or SHARED.
However, the library may still be linked using the file found from disk.
Use of an IMPORTED target is still important to allow per-configuration
files to be specified for the library.
This change creates an UNKNOWN type for IMPORTED library targets. The
IMPORTED_LOCATION property (and its per-config equivalents) specifies
the location of the library. CMake makes no assumptions about the
library that cannot be inferred from the file on disk. This will help
projects and find-modules import targets found on disk or specified by
the user.
Rename the recently added INTERFACE mode of the target_link_libraries()
command to LINK_INTERFACE_LIBRARIES. This makes it much more distinct
from a normal call to the command, and clearly states its connection to
the property of the same name. Also require the option to appear
immediately after the target name to make it a mode rather than an
option.
It is likely that projects or CMake modules in the future will need to
check the value of a policy setting. For example, if we add a policy
that affects the results of FindXYZ.cmake modules, the module code will
need to be able to check the policy.
A recent change fixed a case in which CMake incorrectly diagnosed a
circular dependency involving a non-linkable executable target. This
adds a test for that case.
As of CMake 2.6 a custom command output specified by relative path is
placed in the build tree. This adds a test to make sure other
references to the output are hooked up correctly, fixing a bug in CMake
2.6.1.
- 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
- 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.
Brad King
Zach Mullen
Bill Hoffman
David Cole
Alexander Neundorf
Ken Martin