Move the permissions modification added by commit 88fed668b1 (Make
bundle items writable before fixup, 2010-09-07, v2.8.3~129^2) inside the
condition added by commit 45ed314bff (BundleUtilities: do not run
install_name_tool on scripts, 2020-07-27, v3.19.0-rc1~404^2).
There is no reason to add write permissions to a file that we are
not going to modify.
Fixes: #24424
Commit v3.13.0-rc1~279^2 (GetPrerequisites: Move dylibs from MacOS
to Frameworks folder in bundle, 2018-07-22) introduced a regression
that can cause symlink creation to fail during packaging. Symlinks
can be created before targets are installed, so the destination
directory of the symlink sometimes won't exist at symlink creation.
Fixes: #18726
31b6825bd2 Merge branch 'master' into deployqt4-cmp0080-fix
15bbff0581 DeployQt4: Do not include BundleUtilities at configure time
65bea5b90b DeployQt4: Convert to 2-space indentation
9bfb63bd42 Help: Convert DeployQt4 to block-style comment
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2494
Due to CMP0080, BundleUtilities can no longer be included at
configure-time. However, DeployQt4 contains some functions which
are meant to be used at configure-time, and some which are meant
to be used at install-time and use BundleUtilities. This change
breaks the file into two sections: common functions and install-time
functions. BundleUtilities is now only included at install-time,
thus fixing the policy warning.
Fixes: #18466
* Replace '::' by '.. code-block:: cmake' wherever it makes sense.
* Convert to definition list where appropriate.
* Prefer '<placeholder>' over 'placeholder'.
This command is intended for modules that issue policy warnings so
they can get the warning string from CMake in a uniform manner,
rather than duplicating the string. Several modules been updated
to include an example of the usage of this new command.
This commit adds a new CMake policy, CMP0080, which prohibits the
inclusion of BundleUtilities at configure time. The old behavior is
to allow the inclusion.
Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
The specific cause is when e.g.
/Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgio-2.0.0.dylib
is detected by fixup_bundle. set_bundle_key_values() interprets this as
a framework, thus doing a string replace that creates an embedded_item
that is equal to the original path, i.e. it is not embedded.
The `otool` command may return multiple RPATH entires, so call
`gp_append_unique` for each one. Otherwise we may try to ask
`install_name_tool` to deal with the same entry twice.
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.
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 \)
Some frameworks might be built with the library right at the root
of the framework rather than down in a versioned sub-folder with
a symlink at the root.
Make one of the slashes in the REGEX optional so BundleUtilities
can still properly work with such frameworks ... even if they are
weird. ;-)
Thanks to Tobias Hieta for the bug report and for trying out the fix
before I pushed this commit.
Ancient versions of CMake required else(), endif(), and similar block
termination commands to have arguments matching the command starting the
block. This is no longer the preferred style.
Run the following shell code:
for c in else endif endforeach endfunction endmacro endwhile; do
echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/'
done >convert.sed &&
git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' |
egrep -z -v '^(Utilities/cm|Source/kwsys/)' |
egrep -z -v 'Tests/CMakeTests/While-Endwhile-' |
xargs -0 sed -i -f convert.sed &&
rm convert.sed
51e16c0 BundleUtilities: Avoid test on Watcom dashboards (#12034)
41f962a Revert "BundleUtilities: Run test on Windows if either MSVC or dumpbin was found."
e17135e BundleUtilities: Add rpath to loadable modules in test.
8064044 BundleUtilities: Print reason for not loading module.so
f3de459 BundleUtilities: Run test on Windows if either MSVC or dumpbin was found.
900bf98 BundleUtilities: Disable running test on Windows unless using MSVC.
fa4dc08 BundleUtilities: Fix issues with custom target DEPENDS in test (#12034)
e40b79e BundleUtilities: Fix test when using xcode (#12034)
b68d3dc BundleUtilities: Fix regex to extract dependents from ldd (#12034)
7ac7b43 BundleUtilities: Work w/ non .app exes on Mac (#12034)
When the path to "resolved_embedded_item" was shorter than
the path to the bundle being fixed up, fixup_bundle would
fail with a cmake error like:
"string end index: 110 is out of range 0 - 85"
Detect when the path of resolved_embedded_item is too short
to be embedded in the bundle, and report the proper error
message, so the poor developer reading it has a snowball's
chance of actually fixing the issue.
Also add a test of BundleUtilities including an exe,
some shared libs, a plugin, and a framework-style lib.
This test presently runs (and this functionality works)
on Linux, Mac and Windows.
For now, the framework-style lib is built as a plain old
shared lib because there is another yet-unresolved issue
with local frameworks without rpaths on the Mac.
Also, improve the documentation of the fixup_bundle and fixup_bundle_item
functions to clarify that plugin type "libs" need to be copied into
the bundle *before* calling fixup_bundle.
Commit e93a4b4d34 changed the way that
the libs parameter to fixup_bundle is interpreted. Before the commit,
the libs were copied into the bundle first and then fixed up. After
the commit, the copy was skipped, assuming the libs were in the bundle
in the first place, and then the fixups occurred as before.
However, before the commit, it was possible to name a lib from outside
the bundle, and have it copied in and then fixed up. Its resolved
embedded name was always inside the bundle before. After, its resolved
embedded name was just the same as its resolved name, which is in its
original location, and not necessarily inside the bundle.
This manifested itself as a problem with the ParaView call to
fixup_bundle and its many plugins. Previously, ParaView had simply
passed in the list of plugin file names as they existed in the build
tree, and left the copying into the bundle up to the fixup_bundle
function. When built with CMake 2.8.3 (the first version to contain
the above named commit) the fixup_bundle call would inadventently
fixup libraries in the build tree, not libraries that were in the
bundle. Furthermore, the plugins would not be in the final bundle.
This points out the fact that the fix for the bugs made by the above
commit was a backwards-incompatible change in behavior.
This commit makes it an error to try to fixup an item that is not
already inside the bundle to make the change in behavior apparent
to folks who were depending on the prior copy-in behavior: now,
they should get an error, and hopefully, reading the new and
improved documentation, should be able to resolve it in their
projects by adding code to install or copy in such libraries prior
to calling fixup_bundle.
Whew.
This ensures that any bundle items are made user writable before
any attempt is made to alter them using install_name_tool. This is
because MacPorts/Fink/Homebrew don't install libraries as writable.
This fix is needed to allow fixup_bundle_item to work correctly
when ingesting libraries installed by these package managers.
of http://github.com/themiwi/CMake
into fix-10747
Conflicts:
Modules/BundleUtilities.cmake
There was one newly added function in BundleUtilities.cmake
which also needed the same "documentation at top" treatment.
