Since commit e4beefeb (CTest: Do not munge UTF-8 output in XML files,
2009-12-08) we validate UTF-8 encoding of build and test output as it is
written to XML files. However, in cmCTestTestHandler::CleanTestOutput
we still processed test output one byte at a time and did not recognize
multi-byte UTF-8 characters. Presence of such characters caused early
truncation.
Teach CleanTestOutput to truncate test output at the limit but without
cutting it in the middle of a multi-byte encoding. Also, stop avoiding
truncation in the middle of an XML tag like "<MyElement>" because the
'<' and '>' will be properly escaped in the generated XML anyway.
This patch makes include() and find_package() prefer cmake files
located in CMAKE_ROOT over those in CMAKE_MODULE_PATH.
This makes sure that the including file gets that file included
which it expects, i.e. the one from cmake with which it was tested.
It only changes behaviour when such an included file exists both
in CMAKE_MODULE_PATH and in CMAKE_ROOT.
This comes together with a new policy CMP0017, with default
behaviour it behaves as it always did, but warns.
With NEW behaviour it includes the file from CMAKE_ROOT
instead from CMAKE_MODULE_PATH. This fixes (if CMP0017 is set)
building KDE 4.5 with cmake >= 2.8.3.
Also a basic test for this policy in included.
Check CMAKE_POLICY_DEFAULT_CMP<NNNN> for a default when policy CMP<NNNN>
would otherwise be left unset. This allows users to set policies on the
command line when the project does not set them. One may do this to
quiet warnings or test whether a project will build with new behavior
without modifying code. There may also be cases when users want to
build an existing project release using new behavior for policies
unknown to the project at the time of the release.
The header was included only under "#ifdef __linux", but not all Linux
distributions provide the header. SystemInformation uses no symbols
from this header, so do not include it.
Commit 060d6e88 (Add support for windres to cygwin, 2010-12-23) and
commit b2f308c8 (Add support for windows resources with mingw/msys,
2010-12-22) introduced enable_language(RC) for the first time in a
platform file processed by a bootstrap-built cmake.
667a90a Fix sentence break in add_test documentation
96309fc Make TestsWorkingDirectory test a C file
a4a5e37 Use iostream to make Borland happy
cfe53cd Fully specify the path to old-signature add_test
017d4e9 Group adding tests with its properties
561cc33 Only test the default cwd with Makefiles
d87bae7 Simplify the _default_cwd derivation
992c74f Use --><-- markers to denote the path
5249551 Flip slashes around on Windows
0a014da Add ctype.h include for toupper()
af12f83 Fix header includes for C++ and Visual Studio
5597aa2 Rename the project to match the test
9bf4165 Add tests for WORKING_DIRECTORY arg to add_test
42de5d0 Add WORKING_DIRECTORY argument to add_test
7679f9f Rename WorkingDirectory test
d95f817 Add the WORKING_DIRECTORY property to tests
Pass the lpClass argument of RegCreateKeyEx as a real char[] instead of
a string literal. At least one platform declares the argument as char*
instead of "const char*".
Commit 42de5d02 (Add WORKING_DIRECTORY argument to add_test, 2010-12-16)
added a new sentence to a paragraph without separating it by " " from
the previous sentence. Add the missing spaces.
4499d50 Mark CustomCommand test perconfig.out as SYMBOLIC
f0cdb60 Introduce "generator expression" syntax to custom commands (#11209)
4749e4c Record set of targets used in cmGeneratorExpression
ef9e9de Optionally suppress errors in cmGeneratorExpression
45e1953 Factor per-config sample targets out of 'Testing' test
4091bca Factor generator expression docs out of add_test
bfb7288 Record backtrace in cmCustomCommand
In vs2010 a bad project file could be generated if a .c or .cxx file
was marked with HEADER_FILE_ONLY, if it was in a library that contained
both c and c++ code. This fixes the error in the code, and adds a test
for this case.
If a .sln file refers to a project file with a leading ".\", as in
".\foo.vcxproj" instead of just "foo.vcxproj" or a full path then
msbuild behaves strangely. Whenever target foo is built as a dependency
of another target, msbuild brings multiple configurations up to date
instead of just the requested configuration!
Avoid a leading ".\" in project file references to avoid this behavior.
This alternative fix to that attempted by commit 57e71533 (Avoid msbuild
idiosyncrasy that builds multiple configs, 2010-12-10) avoids use of
full path project file references which vcbuild does not support.
This reverts commit 57e71533f4.
While "msbuild" can handle full paths to project files in solutions,
the old "vcbuild" used for VS < 10 cannot. We will need another
way to fix issue #11594.
For prior versions of Visual Studio we would intentionally pass
"/nologo-" for "verbose makefiles" (CMAKE_VERBOSE_MAKEFILE ON)
when the caller did not already explicitly specify either /nologo
or /nologo-. And we still do. For the prior versions.
This had the side effect of always passing /nologo- for try_compile
operations because try_compile generates projects that have verbose
makefiles on.
However, starting with Visual Studio 10, the compiler emits
"cl ... warning D9035: option 'nologo-' has been deprecated"
when passed "/nologo-".
Therefore, this commit removes setting "/nologo-" for verbose
makefiles in the Visual Studio 10 case to avoid emitting a
warning for every single invocation of the compiler in a given
build.
With Visual Studio 10, we do not set this flag either way
and therefore, the generated project has no value for this
setting and gets Visual Studio's default value, which is
of course "/nologo", which does not produce a warning.
With Visual Studio 10, a caller can still force "/nologo-"
if desired by adding it explicitly to CMAKE_C_FLAGS or
CMAKE_CXX_FLAGS.
One of Cygwin's goals is to build projects using the POSIX API with no
Windows awareness. Many CMake-built projects have been written to test
for UNIX and WIN32 but not CYGWIN. The preferred behavior under Cygwin
in such projects is to take the UNIX path but not the WIN32 path.
Unfortunately this change is BACKWARDS INCOMPATIBLE for Cygwin-aware
CMake projects! Some projects that previously built under Cygwin and
are Cygwin-aware when they test for WIN32 may now behave differently.
Eventually these projects will need to be updated, but to help users
build them in the meantime we print a warning about the change in
behavior. Furthermore, one may set CMAKE_LEGACY_CYGWIN_WIN32 to request
old behavior during the transition.
Normally we avoid backwards incompatible changes, but we make an
exception in this case for a few reasons:
(1) This behavior is preferred by Cygwin's design goals.
(2) A warning provides a clear path forward for everyone who may see
incompatible behavior, and CMAKE_LEGACY_CYGWIN_WIN32 provides a
compatibility option. The warning and compatibility option both
disappear when the minimum required version of CMake in a project is
sufficiently new, so this issue will simply go away over time as
projects are updated to account for the change.
(3) The fixes required to update projects are fairly insignificant.
Furthermore, the Cygwin distribution has no releases itself so project
versions that predate said fixes tend to be difficult to build anyway.
(4) This change enables many CMake-built projects that did not
previously build under Cygwin to work out-of-the-box. From bug #10122:
"I have built over 120 different source packages with (my patched)
CMake, including most of KDE4, and have found that NOT defining
WIN32 on Cygwin is much more accurate." -- Yaakov Selkowitz
A fully compatible change would require patches on top of these project
releases for Cygwin even though they otherwise need not be aware of it.
(5) Yaakov has been maintaining a fork of CMake with this change for the
Cygwin Ports distribution. It works well in practice. By accepting the
change in upstream CMake we avoid confusion between the versions.
CMake itself builds without WIN32 defined on Cygwin. Simply disable
CMAKE_LEGACY_CYGWIN_WIN32 explicitly in our own CMakeLists.txt file.
Previously, we would search in the Windows registry for the path
to makensis, and fail immediately if we could not read the registry
value, assuming that it was simply not installed.
This change looks for makensis in the PATH even if the registry value
is not there, enabling the scenario where makensis is installed without
admin privileges and never even touches HKEY_LOCAL_MACHINE during the
non-admin install.
In VS9 and previous versions, :VCReportError is the goto label
to jump to after a failed custom command. It stops the build
before it tries to go any further.
In VS10, :VCEnd is the correct label to use.
Create a method in the VS generators to provide the correct
line of script to use for each version of Visual Studio.
For more internal details, search for VCEnd in the
C:\Program Files\MSBuild directory.
The KWSys SystemTools::GetMaximumFilePathLength method is poorly
conceived and should not be used. The cmDepends code honors its own
MaxPath buffer size. Just hard-code it.
The first instinct of a lot of users is to use file(GLOB) to assemble
lists of sources. Add a warning to the help text stating that it should
not be used for this purpose and briefly explain why.
Suggested-By: Ryan Pavlik
A cycle exists when the DFS returns to the root node, not just when
multiple paths lead to the same node.
Inspired-By: Alexander Esilevich <aesilevich@pathscale.com>
Evaluate in the COMMAND arguments of custom commands the generator
expression syntax introduced in commit d2e1f2b4 (Introduce "generator
expressions" to add_test, 2009-08-11). These expressions have a syntax
like $<TARGET_FILE:mytarget> and are evaluated during build system
generation. This syntax allows per-configuration target output files to
be referenced in custom command lines.
The target_link_libraries command requires its first argument to be a
target in the current directory. Document this and update the error
message to be more specific. While at it, format the error message with
a call stack.
Previously the OUTPUT arguments of add_custom_command were not
slash-normalized but those of add_library and add_executable were.
This caused the example
add_custom_command(OUTPUT a//b.c ...)
add_library(... a//b.c ...)
to fail at build time with "no rule to make a/b.c". Fix this and modify
the CustomCommand test to try it.
This method replaces '//' with '/' to make the paths look nicer.
Originally it correctly skipped a leading '//' in a UNC path as the
comment says. However, commit "Removed extra variable initializations"
(2005-04-15) accidentally removed the "pos=1" initializer. It was then
incorrectly restored by commit "Added missing variable initialization"
(2005-04-15) as just "pos=0". Restore the proper initializer.
The test for this added by commit "better coverage" (2006-07-31)
included incorrect output for a sample UNC-like path. Fix it.
Pass the full version to cmake_minimum_required(VERSION) in generated
CMake files for try_compile projects. This tells CMake not to use any
backward compatibility behavior while processing code it generates.
Brad King
Alex Neundorf
KWSys Robot
Zach Mullen
Craig Scott
Bill Hoffman
Clinton Stimpson
David Cole
Ben Boeckel
Rolf Eike Beer