When configured to use UTF-8 internally, add a UTF-8 BOM
to generated .sln files for Visual Studio to correctly
handle them.
Otherwise, some versions of Visual Studio will read them
as ANSI encoded files.
When uploading files greater 2GB a cast to 'int' overflows, leading to a
bad alloc when passed to new. Also avoid floating point arithmetic when
integer calculations will work as well.
Reported-by: Justin Borodinsky <justin.borodinsky@gmail.com>
07fc7b75 Tests: Test using objects from a language enabled in a subdirectory (#15325)
fdbfcfdf Ninja: Generate rules only for languages compiled in a target (#15325)
The SunPro Fortran compiler uses "-F" instead of "-E" to request
preprocessing. The output does not go to stdout so use "-o" to
specify the output file.
This fixes the guess originally made by commit b6b37e30 (Makefile: Add
assembly and preprocessed targets for Fortran, 2014-11-05).
bb83cdaa Help: Add notes for topic 'AppleClang-5.1-features'
bd6b42c1 Features: Record for AppleClang 5.1
b341799e Tests: Fix RunCMake.CompileFeatures test NonValidTarget2 case
e2a489c7 Remove some temporary vectors for ExpandListArgument.
0f99feec cmGeneratorExpression: Remove unused header.
722f1a71 CTest: Expand a string directly into a container.
Extract upstream KWSys using the following shell commands.
$ git archive --prefix=upstream-kwsys/ 5a15cb3b | tar x
$ git shortlog --no-merges --abbrev=8 --format='%h %s' 87c65319..5a15cb3b
Brad King (1):
5a15cb3b Base64: Use size_t for lenghts in API
Change-Id: I09a2c5d6b67280f96d580c7b26bf8b2aa0bdb709
The change in commit v3.1.0-rc1~174^2 (Makefile: Handle '#' in
COMPILE_OPTIONS, 2014-08-12) was not compatible with code that
tries to workaround the original bug. Unfortunately there is no
good way to fix the bug in a compatible way. Add a release note
to call attention to the change.
Add a test case that enables CXX in the top level and C in a subdirectory.
Create an executable in the top level that uses C objects compiled in the
subdirectory. Strictly speaking this is not defined behavior for all
language combinations, but happens to work in this case. Test this
behavior since projects might try to use it.
Refactoring in commit v3.1.0-rc1~688^2~2 (cmTarget: Compute languages
from object libraries on demand, 2014-03-18) taught cmTarget::GetLanguages
to (correctly) include the languages of object library sources. Previously
this was done only in cmTarget::ComputeLinkImplementationLanguages to
choose the linker language.
The Ninja generator writes out generic build rules for each language
compiled within a target using the rule variables defined in the
directory of the target. This only needs to be done for languages
actually compiled within the current target. Switch from using the
cmTarget::GetLanguages method to get the list of languages over to
using cmTarget::GetSourceFiles directly so we do not get the languages
in object libraries.
Strictly speaking this should make no difference because it is not safe
to use objects from a language not enabled in the directory containing
a target or else the link information for the language may not be
considered. However, in cases when no link information happens to be
needed for a language it was possible in CMake 3.0 and below to enable
a language only in a subdirectory providing an object library, and then
use the objects from a containing directory. The above change teaches
the Ninja generator to continue working in this case.
Mark the generated source file with the GENERATED property explicitly
since it is not marked automatically as the output of any custom
command. Mark both the 0 and 1 variants so it works no matter the
outcome of the generator expression.
Kitware Robot
Clinton Stimpson
Brad King
Rolf Eike Beer
Christoph Grüninger
Daniele E. Domenichelli
Stephen Kelly
Vladislav Vinogradov