Previously this was used only in multi-configuration generators to
choose the configuration of try_compile and try_run at their build time.
Teach CMake to honor the variable in single-configuration generators as
the CMAKE_BUILD_TYPE.
Factor out generation of SccProjectName, SccLocalPath, and SccProvider
from cmLocalVisualStudio7Generator::WriteProjectStart and call it from
cmLocalVisualStudio7Generator::WriteProjectStartFortran too.
The module header was being placed in the source tree before. Thanks to
Marcel Loose for the patch, this ensures the file is written to the
build tree.
On Windows platforms source files may contain '\' in include directives:
#include "a\b.h"
Normalize these while scanning to use forward slashes. CMake will
convert from forward slashes to the direction preferred by the native
build tools when writing the path to 'depend.make' files.
Show "<variable|string>" explicitly in if() case documentation whenever
auto-dereferencing occurs. Reference its presence from the explanation
at the bottom.
The signature of get_test_property uses argument order
test property VAR
not
test VAR property
Also document the actual behavior when the property is not found.
Some values simply cannot be escaped properly in all contexts for all
native build tools. Document known limitations after the disclaimer
that states so.
Previously the error message for code like
add_executable(myexe does_not_exist/mysrc.c)
mentioned only that "mysrc.c" is not found. Report the directory too.
Remove the example explained by the misleading phrase "CMake will treat
it as if you wrote". This was originally added by commit a73071ca
(modified the if command to address bug 9123 some, 2009-06-12). Later
related information elsewhere in the documentation was corrected and
made precise by commit cb185d93 (Fix if() command and CMP0012 OLD/NEW
behavior, 2009-10-27) but the misleading example was not corrected.
Replace the example with a correct one that more directly covers the
case that typically surprises newcomers. Avoid recommending a "correct"
way to write code because this behavior is always specific to each case.
Also update the main documentation of the behavior to be more explicit.
This test was broken by commit b2f308c8 (Add support for windows
resources with mingw/msys, 2010-12-22) because the test does not set a
resource compiler which is now required on MinGW for the 'RC' language.
Use windres as the resource compiler for the test.
Problem with CMake 2.8.4-rc1: when you launch the NSIS exe installer
on Windows, the default install path shown to the end user is, at first,
"\CMake 2.8".
This problem started occurring when configuring CMake itself with an
older CMake, after adding CPACK_NSIS_INSTALL_ROOT to fix issue 9148.
So... it's a regression from 2.8.3.
I forgot (again) that when you add a new CPack variable, you must
add it to CMake's CMakeCPack.cmake file or else it is empty when
configured with an older CMake. And on Windows, without a bootstrap
build available, the releases are always configured with an older
version of CMake. This may be the last time this has bitten me,
though, because it is now burned into my brain that problems with
CMake's installer itself are inevitably associated with adding new
CPack variables.
In addition to adding a definition for CPACK_NSIS_INSTALL_ROOT,
I've gone ahead and made it differ for the 32- and 64-bit builds
of CMake to give the end user the expected default value for the
Program Files folder for each one.
And, since I was adding a new 32/64 differentiator anyhow, I made
the "NSIS package name" and "installer registry key base" different
for 64-bit builds, too, by appending " (Win64)" to each one.
These address the concerns mentioned in 9148's related issue:
http://public.kitware.com/Bug/view.php?id=9094 (at least as far
as CMake's installer is concerned). 9094 could still use a good
general fix for all projects, though, and remains open for now.
The parent commit added a warning message whenever a required file
does not exist.
As it turns out, the "required" files never exist when built with
Visual Studio Express editions. Add a variable to suppress these
warning messages because only packagers or naive includers of
this file will care to see such warning messages.
We want to warn about this condition by default so that people who
are using InstallRequiredSystemLibraries without understanding it
fully will have a chance of understanding why it's not working in
the event of missing required files.
But we also want to give projects the ability to suppress this warning
(by "project's choice default") so that they can encourage users who
are restricted to using an Express edition to build their project.
Packagers should explicitly use...
-DCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_NO_WARNINGS=OFF
...when building releases. That way, their release build process will warn
them about any missing files, but only if their project CMakeLists files
use a construct similar to CMake's:
IF(NOT DEFINED CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_NO_WARNINGS)
SET(CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_NO_WARNINGS ON)
ENDIF()
Thanks to "J Decker" on the CMake mailing list for pointing out
that one of the MSVC10_CRT_DIR settings was using "VC90" instead
of "VC100".
After fixing that, I added the code to generate a CMake warning
if one of the files we think is "required" does not exist.
Then, with VS10, there were several other problems that the
warning revealed:
- MSVC10_REDIST_DIR needed more PATHS to be found correctly
- the 64-bit directory is named "x64" now, not "amd64" as in
previous VS versions
- manifest files no longer exist as separate files in the
redist subdirectories (they must be built-in as resources
to the dlls...?)
Previously the Xcode generator would rerun CMake only if input file
dependencies in the top-level directory changed. Teach it to depend on
input files from all directories. Other generators already do this.
Reported-by: Johan Björk <phb@spotify.com>
The LSB header files define major() as a macro but if it is ever called
the macro references symbols not available at link time. Improve the
test for major() to actually call the macro and try to link. This
approach is based on upstream libarchive SVN commit 2866 which fixed
libarchive issue 125, submitted in response to CMake issue #11648.
Inspired-by: Tim Kientzle <kientzle@freebsd.org>
Brad King
David Cole
KWSys Robot
Clinton Stimpson
Marcus D. Hanwell
Nicolas Despres
Ben Boeckel