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.
Our CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES setting is no longer needed
because CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES is now populated with the
actual implicit link directories for the current toolchain. The old
values we hard-coded in CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES are not
relevant to modern toolchains, so simply drop them.
Co-Author: Shawn Walker-Salas <shawn.walker@oracle.com>
4bca9401 Improve appearance of CMake .dmg package on OS X
c4b9ee18 CPack/DragNDrop: Update documentation to include new variables
167a4655 CPack/DragNDrop: Optionally run an AppleScript when making a package
9c1dfbfd CPack/DragNDrop: Place the background image file in a hidden folder
47302038 CPack/DragNDrop: Use source file extension for background image
While the DragNDropGenerator supports custom DS_Store and backgrounds,
it is still very hard to automatically setup nice looking packages. The
primary issue is that the DS_Store embeds the name of the volume in the
path to backgrounds, which means that if a package embeds the version in
its volume name a new DS_Store must generated for each release.
Instead one now can use applescript to setup the DS_Store.
This change also ensures that temporary RW image has enough space for
these changes, creating 1 MB dummy padding file, that is later removed
from the image.
Co-Author: Adam Strzelecki <adam.strzelecki@java.pl>
