Visual Studio 14 (2015) complains if a static character array is
declared with more than 65535 elements. This limit should be large
enough for SharedForward clients, so just hard-code that instead of
trying to compute a limit.
* parent-scope-tests:
test: add a test for PARENT_SCOPE with multiple scopes
test: add test for PARENT_SCOPE behavior
Conflicts:
Tests/RunCMake/set/RunCMakeTest.cmake
This reverts commit 5abfde6cb8.
The behaviors associated with implicit pulldown on variable lookup
seriously conflict with the optimizations made in these commits.
Basically, since values were copied upon variable lookup, not just on
PARENT_SCOPE, coupled with PARENT_SCOPE's behavior based on whether the
variable is in the current scope or not causes serious problems with not
storing a value for every variable at every scope.
The commit changed behavior of the following example, among other cases:
function(test_set)
set(blah "value2")
message("before PARENT_SCOPE blah=${blah}")
set(blah ${blah} PARENT_SCOPE)
message("after PARENT_SCOPE blah=${blah}")
endfunction()
set(blah value1)
test_set()
message("in parent scope, blah=${blah}")
Reported-by: Alex Merry <alex.merry@kde.org>
Reported-by: Ben Cooksley <bcooksley@kde.org>
Update the wording of some examples to avoid long lines in code blocks.
Otherwise the formatted documentation can exceed certain column width
limitations.
Convert several preformatted code block literals that enumerate lists of
options or variables to use reST definition lists instead. Manually
wrap other long lines in code blocks.
The iOS product type 'com.apple.package-type.bundle.unit-test' requires
code signing on Xcode 6. Other iOS target types do too. Until CMake
learns to add the CODE_SIGN_IDENTITY build attribute itself, toolchain
files can set CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY to tell the Xcode
generator to add the attribute. Teach CMakeDetermineCompilerId to
recognize this variable and add the CODE_SIGN_IDENTITY build attribute
to the compiler id project.
Since commit 0cce556b (Xcode: Use sysroot and deployment target to
identify compiler, 2014-04-29) our compiler id detection project uses
the target platform SDK in case Xcode selects a different compiler based
on it. Now the compiler id project actually compiles with the target
compiler and SDK when cross-compiling.
The iOS tools do not support the 'com.apple.product-type.tool' product
type we use in our compiler id detection project. When targeting
iPhone, use product type 'com.apple.product-type.bundle.unit-test'
instead.
This restores Qt SDK 4.8 and OS X >= 10.6.5 codesign compatibility
improving embedding frameworks using correct bundle layout described at:
https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html
1. If Versions/VERSION/Resources/Info.plist is missing, well known
incorrect locations are checked for Info.plist and Info.plist is
copied from there, otherwise codesign will fail.
2. Root framework symlinks to binary and Resources are restored to
point inside Versions/Current, otherwise Qt 4.8 looking for
Resources/ in framework root will fail.
Changes in commit b9aa5041 (cmLocalGenerator: Simplify GetIncludeFlags
output formatting, 2014-03-04) caused Windows Resource Compiler include
directories to be computed as relative paths in the Ninja generator.
This breaks the cmcldeps handling of include paths. The reason for the
regression is that several cmLocalGenerator::GetIncludeFlags callers
treated the fourth "bool forResponseFile" argument as if it controlled
whether include directories were a full path. It actually did control
that by accident until the above commit.
Add an explicit "bool forceFullPaths" argument to GetIncludeFlags
and thread the value through ConvertToIncludeReference as needed.
Update GetIncludeFlags call sites that really wanted to control the
forResponseFile setting to be aware of the new argument. Extend the
VSResource test to cover this case.
Add section headers similar to the 3.0 release notes and move each
individual bullet into an appropriate section. Highlight the new VS
generator capabilities for Windows Phone, Windows Store, and NVIDIA
Nsight Tegra with dedicated subsections.
Move all development release notes into a new version-specific document:
tail -q -n +3 Help/release/dev/* > Help/release/3.1.0.rst
git rm -- Help/release/dev/*
except the sample topic:
git checkout HEAD -- Help/release/dev/0-sample-topic.rst
Reference the new document from the release notes index document.
Add a title and intro sentence to the new document by hand.
631fadea Help: Add notes for topic 'fix-OSX-bundle-rpaths-and-Qt5'
50e261dd OSX: Warn when attempting to change runtime paths on OS X 10.5
9b98fd52 cmake-gui: Make sure we bundle Qt5 Cocoa platform plugin
83a06bb4 BundleUtilities: Framework codesign Resources/Info.plist & Current
f7df82ac BundleUtilities: Resolve & replace @rpath placeholders
14bc686f GetPrerequisites: Make sure dyld placeholders are prefixes
6c313797 BundleUtilities: Use find on UNIX for fast executable lookup
Even though 10.5 supports @rpath, the support is not complete
enough for CMake. For instance, install_name_tool doesn't support
adding and removing rpaths.
Also modifying BundleUtilities test to remove an undesirable cmake
generated runtime path. The intent was to build with the install
rpath as is done with the other cases in this test.
This is done by gathering LC_RPATH commands for main bundle executable and
using it for @rpath lookup in dependent frameworks.
All functions that need to carry rpaths to now take optional <rpaths> argument.
This enabled apps using @rpath to be bundled correctly, which will be necessary
for upcoming Qt 5.4 that will use @rpath for all frameworks.
Check that install_name_tool has -delete_rpath before using it.
Otherwise it will fail with Xcode 3.x on 10.5 which has no -delete_rpath
option for install_name_tool command, that was first introduced in 10.6
SDK, even that 10.5 supports LC_RPATH and @rpath.
It makes whole executable process quicker on UNIX, especially for large bundles
containing many files, since using find narrows results to only files having
executable flags then all further tests follow.
Since find ... -perm +0111 is not clearly POSIX compliant and some Linux
versions refuse it, it is better to use longer but portable:
find ... -perm \( -perm -0100 -o -perm -0010 -o -perm -0001 \)
Brad King
Ådne Hovda
Ben Boeckel
Clinton Stimpson
Adam Strzelecki
Kitware Robot
Geoff Viola
Peter Wu