- Jul 30, 2014
-
-
Brad King authored
-
Brad King authored
In commit v3.0.0-rc1~551^2~1 (Check*CompilerFlag: make C and CXX modules share most error patterns, 2013-08-08) a pattern containing a ';' was moved out of a ""-quoted argument and into a variable. CMake flattens the containing list and breaks the pattern. Use a '.' to match ';'.
- Jul 28, 2014
-
-
Brad King authored
-
Brad King authored
-
Brad King authored
Xcode 6 introduced an 'OTHER_LIBTOOLFLAGS' setting for the "Other Librarian Flags" of a static library. Now 'OTHER_LDFLAGS' are ignored. Teach the Xcode generator to choose the correct name for the build setting based on the type of target and the version of Xcode. Inspired-by: Jamie Kirkpatrick <jkp@spotify.com>
-
While at it, update QT_QTGUI_PLUGINS to use QT_IMAGEFORMATS_PLUGINS instead of duplicating the list.
-
- Jul 17, 2014
-
-
Brad King authored
-
Brad King authored
-
The error is caused by a workaround for UNICOS. The workaround incorrectly uses the _CRAYC macro to determine if building for UNICOS. This macro will always be defined for the Cray C and C++ compiler regardless of the target platform, even when building for Linux. The correct macro should be _CRAY, which as per Cray documentation is only defined for UNICOS targeted builds.
-
Brad King authored
-
Commit v3.0.0-rc1~111^2 (QNX: Introduce QCC compiler id for that QNX platform compiler., 2014-01-20) split handling of the QNX QCC compiler into a separate compiler-id. That refactoring results in the QCC compiler not using the CMake-compiler-id "GNU", which means that the __compiler_gnu macro is no longer executed for it. Add Compiler/QCC*.cmake modules to define and call the __compiler_qcc macro and teach it to call __compiler_gnu internally. Remove the corresponding pieces from the Platform/QNX*.cmake modules. It is also necessary to change the language conditional to dereference the lang macro parameter, which is another bug introduced by the same commit. The extra -lang-c++ flag is only necessary when the CXX compiler is specified as 'qcc' instead of 'QCC' in the toolchain file, which is why this bug was not noticed before. The flag is also necessary in that case when linking in order to find the appropriate standard libraries. The flag was not previously added when linking executables, so linking failed even with CMake 2.8.12 with the lower-case compiler-id. Co-Author: Brad King <brad.king@kitware.com>
-
- Jul 10, 2014
-
-
Brad King authored
-
Brad King authored
On WinCE we must link both shared libraries and executables with the /subsystem:windowsce flag. Teach Platform/Windows-MSVC to pass it to the linker in both cases. Suggested-by: Gunnar Roth <gunnar.roth@gmx.de>
-
Brad King authored
-
Install CFBundles as directories just like frameworks and application bundles.
-
- Jul 07, 2014
- Jun 25, 2014
-
-
Brad King authored
-
Brad King authored
The check for this flag added by commit v3.0.0-rc1~284^2 (UseSWIG: Name python module according to swig flags, 2013-11-26) can get false positives on flags like "-noproxydel". Improve the check to match only "-noproxy". Suggested-by: Garth Wells <gnw20@cam.ac.uk>
-
Brad King authored
-
Brad King authored
Since commit v3.0.0-rc1~374^2 (Refactor internal resource location APIs and initialization, 2013-11-07) a bootstrap-built "cmake" tries to reference "ctest" and "cpack" executables next to itself, which never exist. Teach cmSystemTools::FindCMakeResources, when bootstrap-built, to refer to the "ctest" and "cpack" executables in the location where they will be built after "make".
-
Brad King authored
Rename CMAKE_ROOT_DIR to CMAKE_BOOTSTRAP_SOURCE_DIR to clarify both that it is only for bootstrap and that it refers to the source directory.
-
- Jun 23, 2014
-
-
Brad King authored
-
Brad King authored
From the GCC 4.9 release notes for Fortran: https://gcc.gnu.org/gcc-4.9/changes.html "Module files: The version of the module files (.mod) has been incremented; additionally, module files are now compressed." Teach cmDependsFortran::ModulesDiffer to look for the gzip magic numbers at the beginning of the module file. If found, assume the module was produced by gfortran >= 4.9. The modules do not appear to contain the date as earlier versions did so we can compare the content directly and do not actually need to decompress.
-
- Jun 16, 2014
-
-
Brad King authored
-
It may happen that CMake include is an explicit dependency for some command, while all CMake includes are set phony in WriteTargetRebuildManifest, this may lead to duplicate phony generate rules which causes ninja warnings. We need to remove implicit CMake includes in WriteUnknownExplicitDependencies. This fixes FindCUDA ninja warnings.
-
- Jun 12, 2014
-
-
Brad King authored
-
Brad King authored
Since commit v2.8.12~300^2~1 (CLI: Suppress the unused warning if the key value pair is cached, 2013-05-16), cmake::SetCacheArgs saves a cachedValue pointer and may cause the memory to be freed (by setting the cache entry) before reading it again. Fix this by saving the old value in a separate string.
-
- Jun 09, 2014
-
-
Brad King authored
-
Newer HP-UX versions (e.g. 11.31) also offers F_SETTIMES, but with a different struct for the timing information. Suggested-by: Eric Berge <ericmberge@gmail.com>
- Jun 05, 2014
-
-
Brad King authored
-
Without it the option list is cut short after --debug.
-
- Jun 03, 2014
-
-
Brad King authored
-
Brad King authored
If we fail to create the generator named by CMAKE_GENERATOR, exit with an error message instead of crashing. While at it, fix the wording of the error message when CMAKE_GENERATOR is not set. Extend the RunCMake.CommandLine test with cases covering the "cmake --build" option when the named directory does not provide a CMakeCache.txt with a valid CMAKE_GENERATOR.
-
Brad King authored
-
Brad King authored
Use the name "Kitware" rather than "Kitware, Inc." to simplify the text. Provide a CMake-specific URL.
-
Brad King authored
-