- Mar 08, 2016
-
-
Brad King authored
-
Brad King authored
-
3aa6fea6 VS: Fix VS 2015 .vcxproj debug setting for older toolsets (#15986)
-
72e0dc58 Diagnose recursive project/enable_language without crashing (#15999)
-
743f2a80 FindPython{Interp,Libs}: Clarify recommended call order
-
3f15665a VS: Fix VS 2015 .vcxproj debug setting for v100 toolset (#15986)
-
Kitware Robot authored
-
- Mar 07, 2016
-
-
Teach the Ninja generator to add the `-current_version` and the `-compatibility_version` flags based on the VERSION and SOVERSION target properties just as the Makefile generators do. Signed-off-by:
Bruce Stephens <bruce.r.stephens@gmail.com>
-
Move this method from cmMakefileLibraryTargetGenerator so it can be re-used for the Ninja generator too. Signed-off-by:
Bruce Stephens <bruce.r.stephens@gmail.com>
-
Brad King authored
Calling `project()` or `enable_language()` from a toolchain file will infinitely recurse since those commands load the toolchain file. Diagnose and reject this case with an error message instead of crashing when the stack eventually overflows.
-
Brad King authored
-
Brad King authored
Improve wording in our advice about how to call both of these modules.
-
Brad King authored
-
Brad King authored
Since commit v3.4.2~2^2 (VS: Fix VS 2015 .vcxproj file value for GenerateDebugInformation, 2016-01-08) we generate invalid project files for the v110 and v120 toolsets. VS complains: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(639,9): error MSB4030: "Debug" is an invalid value for the "GenerateDebugInformation" parameter of the "Link" task. The "GenerateDebugInformation" parameter is of type "System.Boolean". This reveals that our VS flag map selection should be based on the toolset instead of the version of VS. However, that will be a non-trivial change so for now fix this particular use case by hard-coding a correction to the flag map. Reported-by:
Gregor Jasny <gjasny@googlemail.com>
-
Brad King authored
-
3906ca5a BundleUtilities: Fix regression handling frameworks
-
d4482dd9 CPackWIX: Support binary-only WiX installations
-
b682debd Utilities/Release: Switch to OS X 10.7 and Qt 5.5 for Mac binary
-
6122909c VS: Add option to set `ConfigurationType` of a .vcxproj file
-
190a5fdf Automatically use OpenSSL by default on Linux and FreeBSD if available
-
Fix logic error introduced in commit e422f738 (BundleUtilities: Fix treatment of .dylib inside .framework folders, 2016-02-11).
-
Kitware Robot authored
-
- Mar 06, 2016
-
-
Kitware Robot authored
-
- Mar 05, 2016
-
-
Kitware Robot authored
-
- Mar 04, 2016
-
-
Kitware Robot authored
-
- Mar 03, 2016
-
-
Kitware Robot authored
-
- Mar 02, 2016
-
-
Kitware Robot authored
-
- Mar 01, 2016
-
-
Also fix URLUPDATEINFO -> ARPURLUPDATEINFO reference in CPACK_WIX_PROPERTY_<PROPERTY> examples. Reviewed-by:
Nils Gladitz <nilsgladitz@gmail.com>
-
Kitware Robot authored
-
- Feb 29, 2016
-
-
Brad King authored
Since https is almost ubiquitous nowadays we should support it by default whenever possible. When building our own curl, we already automatically enable SSL/TLS support on Windows and OS X by using the OS-native APIs. On UNIX platforms we need to use OpenSSL but have not done so by default before, leading to possible user confusion when https transfers fail later. Fix this by searching for OpenSSL quietly and enabling use of it automatically if it is found. Do this only on Linux and FreeBSD for now because on other UNIX platforms (e.g. AIX, HP-UX, SunOS) it seems too easy to find an OpenSSL that is not compatible with the target compiler.
-
Kitware Robot authored
-
- Feb 28, 2016
-
-
Kitware Robot authored
-
- Feb 27, 2016
-
-
Kitware Robot authored
-
- Feb 26, 2016
-
-
Add a VS_CONFIGURATION_TYPE target property to set this value explicitly. This is useful to build a Windows Kernel Mode Driver, for example.
-
f3ac0651 Improve compiler check message on non-Make generators
-
bc29ed54 CTest: Make coverage file selection more specific.
-
7f1bd9fe try_compile: Add option to control type of target
-
6c9586f9 file(DOWNLOAD): Fill STATUS variable on hash mismatch (#15987)
-