Since jsoncpp 0.7.0 (2014-11-20) the upstream may provide a CMake
package configuration file such that find_package(jsoncpp) will find a
jsoncppConfig.cmake file. In order to avoid conflicting with this
(especially on case-insensitive filesystems), and since we always prefer
projects to provide package config files (that they maintain), it is
better to not provide FindJsonCpp publicly.
Move FindJsonCpp into a private source directory that is not installed
so that we can still use it for building CMake itself.
Reported-by: Ryan Pavlik <ryan.pavlik@gmail.com>
The libarchive APIs use nl_langinfo(CODESET) for iconv so they need the
locale to be set for LC_CTYPE. However, the rest of CMake does not
define any behavior for non-ASCII character classification/conversion so
we do not want to setlocale() globally. Add a RAII class to save, set,
and restore the locale around calls to libarchive APIs.
Inspired-by: Clinton Stimpson <clinton@elemtech.com>
Revert the changes made by commit v3.1.0-rc1~406^2~1 (Encoding: Add
setlocale() to applications, 2014-05-30) and commit v3.1.0-rc1~406^2
(Encoding: Change to only set LC_CTYPE, 2014-06-11), and other setlocale
calls added later in their spirit. CMake has not been taught how to
deal with non-C locales everywhere. We do not define any functionality
for character conversions for non-ASCII strings. Another solution will
be needed to address the original problem motivating addition of
setlocale() calls.
The CMAKE_<LANG>_STANDARD_DEFAULT variable indicates whether the
compiler has any notion of standard levels and that CMake knows
about them. If no language standard levels are available, skip
all logic to attempt to add a flag for the level.
Also fail with an internal error if a bad default value is set.
The refactoring in commit v3.1.0-rc1~812^2~16 (stringapi: Pass
configuration names as strings, 2014-02-09) broke the code path in
cmLocalGenerator::GenerateInstallRules that intends to pick a default
install configuration for multi-config generators. Fix the logic to
select an empty default configuration only when using a single-config
generator whose CMAKE_BUILD_TYPE is not set.
Inspired-by: Roman Wüger <roman.wueger@gmx.at>
Reported-by: NoRulez <norulez@me.com>
When staging the package installation, if the first file in a directory
happens to be a symbolic link, make sure we create the directory before
trying to create the link.
When staging the package installation, if the first file in a directory
happens to be a symbolic link, make sure we create the directory before
trying to create the link.
In commit v3.0.0-rc1~222^2 (Makefile: Allow "gmake target1 target2 -j",
2013-12-18) we added generation of a .NOTPARALLEL rule and told the
generator it is "symbolic" because the file will never be created.
This causes ".PHONY" to be used. However, "clearmake" does not support
parsing of .PHONY specifically for .NOTPARALLEL, so simply drop it.
This should not affect the role of the .NOTPARALLEL rule for GNU make.
The "/showIncludes" flag is only available with MS C and C++ compilers,
and on compilers that "simulate" them (like Intel for Windows). Fix our
logic to choose this type only for MS tools with these languages. All
other cases need to use "deps = gcc" and define DEP_FILE in the build
rule.
Define an empty string in CMAKE_<LANG>_STANDARD_DEFAULT to mean that
the toolchain has no notion of lanuage standard levels. In this case
the <LANG>_STANDARD[_REQUIRED] properties will have no effect.
Update the RunCMake.CompileFeatures test to exclude the
LinkImplementationFeatureCycle test when there is no standard default.
It can never fail because no use of specific features will adjust the
CXX_STANDARD level required for any target since the standard levels
have no meaning in this case.
Otherwise building such projects gives:
warning APPX1901: The DefaultLanguage property is either missing from
the project file or does not have a value
ab9fa54d Xcode: Switch to internal CMAKE_MAKE_PROGRAM lookup by generator (#15324)
11e2e6ca Xcode: Select make program at build time
e4055a61 Xcode: Add internal API to find xcodebuild
The "cmakexbuild" wrapper is not needed for Xcode 4 and above, and the
path to it may change when CMake moves. Avoid storing a specific path
to a build program in CMakeCache.txt and instead compute the value for
CMAKE_MAKE_PROGRAM on demand. However, if a user does set the value
explicitly then honor it.
This does for Xcode what commit v3.0.0-rc1~260^2~4 (VS: Switch to
internal CMAKE_MAKE_PROGRAM lookup by generators, 2013-11-15) did for
Visual Studio generators.
Extend the change made in commit v3.0.0-rc1~260^2~16 (Teach
GenerateBuildCommand to find its own make program, 2013-11-13) to have
the Xcode generator pick between "xcodebuild" and CMake's own copy of
"cmakexbuild" at build time based on the version of Xcode.
Teach the Xcode generator to compute the location of this tool or the
cmakexbuild wrapper. Add internal APIs to get the locations on demand.
Use the "cmakexbuild" wrapper for Xcode < 4, and "xcodebuild" for modern
Xcode.
The "No rule to make target" error message of gmake is not correctly
recognized since GNU make changed the quoting style in commit 23c2b99e9d
(Convert all "`'" quotes to "''" per new GNU Coding Standard guidelines,
2012-03-04). Fix our regex to match both old and new quoting styles.
Brad King
Nils Gladitz
Kitware Robot
Stephen Kelly
Ben Boeckel
Bill Hoffman
Robert Goulet
Marco Nolden