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
7e0b001 Fix missed _POLL_EMUL_H_ and HAVE_POLL combo
8a61950 Toss out strerror_r macros
44fca8b Check for poll when looking for _POLL_EMUL_H_
8d36890 Use _POLL_EMUL_H_ instead of HAVE_POLL_FINE
c5cbb31 Ignore strerror_r since CMake isn't threaded
86979e4 Change cpack run and verify script to work with multi-config generators.
cdf92c9 Precise the project config type when invoking cpack
08f829b Arrange output in a better way
58bd4f2 CPackTest spit out more output in case of failure
dd2a5aa CPack Default component test for ZIP should be OK
88b7f42 CPack new tests for component install
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.
KWSys Robot
Brad King
Zach Mullen
Bill Hoffman
Clinton Stimpson
David Cole
Ben Boeckel