4986d52 Use CPACK_xxx and CMAKE_xxx in a consistent way.
f90223c Fix KWStyle warning
47f0dbd CPack add necessary check to detect/warns/error on ABSOLUTE DESTINATION
6ba055b CPack add easy possibility to warn about CPACK_SET_DESTDIR
Commit "KWSys: Fix SystemTools environment memory handling" (2012-04-26)
added a _WIN32 case inside !KWSYS_CXX_HAS_ENVIRON_IN_STDLIB_H to dllimport
the "environ" global. Howver, KWSYS_CXX_HAS_ENVIRON_IN_STDLIB_H is true
on every Windows toolchain we support so the case is never reached.
Furthermore, even if it were reached the use of dllimport is incorrect
because the toolchain might not be compiling with a dynamic runtime
library. Remove the unused incorrect line and supporting conditionals.
Fortran sources that pass through the C preprocessor may use
#include "header"
syntax or
#include <header>
syntax. CMake already follows the former. Teach it to follow the
latter.
More generally add the check for possible generator "activation" at
runtime depending on a generator specific check.
The dynamic behavior is currently implemented only for MacOS
and should be fully backward compatible for other system.
Inspired-By Tom Hughes <tomtheengineer@gmail.com>
CMAKE_xxx vars are now used in the CMake-generated cmake_install.cmake
script while CPACK_xxx equivalent vars are used from within CPack.
CPack is responsible for getting/forwarding definitions of
CPACK_xxxx var corresponding to CMAKE_xxxx when invoking
CMake-generated install scripts.
As a consequence:
CMAKE_ABSOLUTE_DESTINATION_FILES
CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
may be used from outside CPack as well.
e.g.
cmake -DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=1 -P cmake_install.cmake
works as expected.
c806b23 CDash now supports lots of files in coverage. So, show all files.
761d931 Do not try to run bullseye coverage if COVFILE env is empty.
5b69ce4 Update test data to match new coverage format.
1b418f1 Change GT.M Coverage Parser global
b0c07a1 Disable bullseye coverage for mumps coverage test.
0a169e6 Remove uncovered files from cache coverage data.
a7abf5e Add ability to specify more than one package directory or coverage directory.
220afca Use <TARGET_FILE> expression to run ctest so it works with Xcode and VS IDE.
62f6bce Use a script to run the test because WORKING_DIRECTORY is not in 2.8.2.
f5c5db0 Fix some warnings and a bug where it went past the length of a vector.
7955e99 Add support for Cache coverage.
a86cd33 Add virutal destructor to silence warning.
319eeb0 Add test for mumps coverage. Also refactor code to prepare for cache coverage.
72210c2 Fix line length.
dd07161 Fix warning about char* instead of const char*.
e6412e0 Add support to ctest for GTM mumps coverage.
In trace mode ('--trace'), any 'elseif' or 'else' commands that are
evaluated as part of a conditional block will be printed. Previously,
only the opening 'if' command of a conditional block was printed.
The [usually] wrong usage of absolute DESTINATION in INSTALL rules
keeps popping-up on the ML. We shall have some way to:
1) easily detect it.
2) forbids this for some CPack generator like NSIS
In fact it should certainly be forbidden for *any* generators
when used on Windows but we may implements that on top of the current
patch.
The patch ask the task to the generated cmake_install.cmake scripts.
Those scripts are a little bit more complicated with that but
iff there are absolute DESTINATION. This cost nothing if relative
DESTINATION are used.
Two new vars are introduced (and documented to handle that):
CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
and
CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
Until now an unnamed component was always named "Unspecified".
Now this name is taken from the new cmake variable CMAKE_INSTALL_DEFAULT_COMPONENT_NAME,
which is initialized to "Unspecified". But it can now be set to something
project-specific, per directory
Alex
The coverage global should be in the local namespace. This means the global
will be ^ZZCOVERAGE instead of ^COVERAGE. Change the parser to look for ^ZZCOVERAGE
instead of the old ^COVERAGE
Header files listed in a target's PUBLIC_HEADER or similar properties
are marked as OS X Framework content. Refactoring performed by
commit 11d9b211 (Add cmGeneratorTarget to represent a target during generation, 2012-03-07)
commit 45c2f932 (Simplify cmMakefileTargetGenerator using cmGeneratorTarget, 2012-03-07)
commit 328c0f65 (Simplify cmVisualStudio10TargetGenerator source classification, 2012-03-19)
and related commits accidentally removed such files from treatment as
normal header files by the VS generator (generators other than Makefiles
and Xcode). Move handling of such files out of cmGeneratorTarget and
back to cmMakefileTargetGenerator. The central cmGeneratorTarget
classification will always treat them as header or extra sources.
The hash_fun.hxx header is configured whether FundamentalType is enabled
or not and so cannot depend on it. Run the relevant platform tests
whether or not FundamentalType is on and configure the result directly
into hash_fun. While at it, remove the dependence of SystemInformation
on FundamentalType too since it needs only information that we now
always compute.
d931ce9 VS10: Generate relative source paths when possible (#12570)
b2e7c7a VS11: Do not use source path conversion workaround specific to VS 10
4248132 VS10: Convert paths normally unless forced to relative
c2ba6ba VS10: Simplify vcxproj.filter file generation
4f2d9d2 VS10: Refactor custom commands to use WriteSource