The change in commit f88533cc (CPackDMG: Add support for multilingual
SLAs, 2015-10-19) accidentally used CPACK_DMG_LANGUAGES in its
implementation instead of the intended CPACK_DMG_SLA_LANGUAGES added to
the documentation.
In commit v3.4.0-rc1~18^2 (Disable shared library support when compiler
links statically, 2015-09-30) we tried to detect when the compiler is
not capable of linking shared libraries (possibly due to flags in use).
However, the approach is not robust against flags like `-nostdlib`.
Revert it for now pending another solution to the original problem.
65b86612 Merge branch 'backport-fix-autodef-bigobj-64' into fix-autodef-bigobj-64
c7ddc5f4 Fix auto export symbols for Dlls containing /bigobj for 64bit builds.
75004280 Fix auto export symbols for Dlls containing /bigobj for 64bit builds.
This fixes a bug where 64 bit builds with /bigobj incorrectly determined
that the object files were not 64 bit. This manifested itself with
printf type functions showing up as undefined because the leading
underscore was being removed and should not be removed.
This fixes a bug where 64 bit builds with /bigobj incorrectly determined
that the object files were not 64 bit. This manifested itself with
printf type functions showing up as undefined because the leading
underscore was being removed and should not be removed.
If a custom command has a SYMBOLIC output (that is never actually
created) then do not mark the custom command build statement as
'restat'. Otherwise other custom commands that depend on the symbolic
output may not always re-run because after running the first custom
command Ninja 'restat' will detect that the output timestamp did not
change and skip its dependents.
This was observed with the ExternalProject BUILD_ALWAYS option where
Ninja would not re-run the 'install' step each time 'build' re-runs.
Move generation of 'restat = 1' from the CUSTOM_COMMAND rule to every
build statement using it. This will allow future selection of this
option on a per-custom-command basis.
Prior to commit v3.4.0-rc1~71^2 (Project: Determine default language
dialect for the compiler, 2015-09-15) we always guessed the default
language standard dialect based on the compiler version. This was not
reliable so that commit switched to computing the default language
standard dialect while detecting the compiler id.
When a toolchain file uses CMakeForceCompiler to set the compiler id
then the detection does not occur. Therefore commit v3.4.0-rc1~54^2
(Project: Don't require computed default dialect if compiler was forced,
2015-09-22) made the lack of detection an error only if the compiler was
not forced. However, this means that projects using CMakeForceCompiler
no longer even get the guess that we had before so <LANG>_COMPILER does
not work.
Due to the sophistication of CMake's compiler detection logic projects
should be ported away from using CMakeForceCompiler. In the meantime,
restore a guess of the default language standard dialect when the
compiler is forced.
Our check of CMAKE_PLATFORM_NO_VERSIONED_SONAME, originally added by
commit v3.1.0-rc1~416^2 (Add basic Android platform module, 2014-06-06),
was dropped accidentally by commit v3.4.0-rc1~250^2~21
(cmGeneratorTarget: Move GetLibraryNames from cmTarget, 2015-08-04).
Restore the check in the new location of the GetLibraryNames method.
Our check of CMAKE_PLATFORM_NO_VERSIONED_SONAME, originally added by
commit v3.1.0-rc1~416^2 (Add basic Android platform module, 2014-06-06),
was dropped accidentally by commit v3.4.0-rc1~250^2~21
(cmGeneratorTarget: Move GetLibraryNames from cmTarget, 2015-08-04).
Restore the check in the new location of the GetLibraryNames method.
In commit v3.4.0-rc1~71^2 (Project: Determine default language dialect
for the compiler, 2015-09-15) we added an "INFO:..." string to the
compiler id detection binary. The value can be optimized out of the
compiler id binary unless we force it to be included by making the
program behavior depend on it at runtime. Add references to the value
as we do for the other info strings already.
Gentoo-Issue: https://bugs.gentoo.org/show_bug.cgi?id=565744
MS tools have a limit on the number of symbols that can be listed
in a `.def` file. If multiple `.obj` files provide a symbol then
avoid listing it more than once in the generated `.def` file to
avoid counting toward the limit.
Refactoring in commit v3.4.0-rc1~74^2~1 (MSVC: Rewrite manifest file
handling with Makefile and Ninja, 2015-09-15) broke handling of this
option. Fix it and add a test case.
The -T parameter to CMake may now be specified through cmake-gui via a
new text field in the first-time configure wizard (below the generator
chooser).
The generator factories specify whether or not they support toolsets.
This information is propagated to the Qt code and used to determine if
the selected generator should also display the optional Toolset widgets.
Brad King
Simon Levermann
Bartosz Kosiorek
Kitware Robot
Bill Hoffman
Ty Smith
Chuck Atkins
Robert Dailey