283a48403f CPack/RPM: Fix detection of RPM support for weak dependencies
ab4e74ad0b CPack/RPM: Remove redundant conditions for presence of rpmbuild
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10403
Add a missing `find_program` call to populate `RPM_EXECUTABLE`.
This was left out of two previous changes that intended to query
the `rpm` executable:
* In commit 9b53eca317 (CPack/RPM: Fix weak dep support, 2021-06-29,
v3.21.0-rc2~4^2), without `RPM_EXECUTABLE` the query always failed,
so we were concluding that weak dependencies are not supported even
when they are.
* In commit 488de6294a (CPack: correctly perform querytags on old
versions of RPM, 2025-01-09, v4.0.0-rc1~182^2~3), without
`RPM_EXECUTABLE` the query always failed. This change has not
yet been in a release anyway.
Also fix the test case for the "suggests" field to verify this.
Issue: #22350
Reported-by: Balazs Kosaras <balazskosaras@gmail.com>
When doing successive matches, track the input start and current search
start positions separately to prevent the `^` anchor from matching in
the middle of the string. Add policy CMP0186 to provide compatibility.
Issue: #26629Fixes: #16899
785523a136 Remove compatibility with CMake versions older than 2.8.0
35282387ea CMP0014: Remove support for OLD behavior
fad9c55b8b CMP0013: Remove support for OLD behavior
98a59ba8ad CMP0012: Remove support for OLD behavior
3c0dbb66f5 CMP0011: Remove support for OLD behavior
cf832e75bc CMP0010: Remove support for OLD behavior
77f8c374f3 CMP0009: Remove support for OLD behavior
43ef139567 CMP0008: Remove support for OLD behavior
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !10188
On Alt Linux, some tests that rely on debuginfo and/or rpm
config (using buildroot related binary `brp-alt`), can not succeed.
They produce errors like "package do not have URL as expected",
"source_package-buildroot: No such file or directory", and
"non-stripped binaries don't contain .debug sections".
These tests are disabled by this commit in case of `brp-alt` found.
In commit 2ef966bc77 (Testing: Add test for CPack External generator,
2018-06-11, v3.13.0-rc1~361^2~2) this test was added without defining
its `get_test_prerequirements` function, so it has been re-using the
conditions from the previous test type (STGZ).
53991e62da CPack/RPM: Append .rpm to CPACK_RPM_FILE_NAME if missing
f2a6d423da CPack/DEB: Append .deb to CPACK_DEBIAN_FILE_NAME if missing
907d4db558 Help: Format allowed CPACK_{DEB,RPM}_FILE_NAME values as definition list
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8880
Previously we issued an error when the `.rpm` suffix is missing.
Instead, append the suffix automatically. This matches the behavior of
`CPACK_ARCHIVE_FILE_NAME`, to which the archive format suffix is
automatically appended. With this change, developers can simply do
set(CPACK_RPM_comp_FILE_NAME "${CPACK_ARCHIVE_comp_FILE_NAME}")
Previously we issued an error when the `.deb` or `.ipk` suffix
is missing. Instead, append the suffix `.deb` automatically.
This matches the behavior of `CPACK_ARCHIVE_FILE_NAME`, to
which the archive format suffix is automatically appended.
Since commit 3958ed878f (LCC: Add policy CMP0129 regarding interpreting
LCC as GNU, 2021-10-19, v3.23.0-rc1~508^2) we intended to enable policy
`CMP0129` in RunCMake tests via `-DCMAKE_POLICY_DEFAULT_CMP0129=NEW`.
Fix the condition activating that to check `CMAKE_C_COMPILER_ID` where
it is always available.
Remove now-unnecessary CMP0129 settings in RunCMake cases.
For policy-specific tests, use the version before the policy was
introduced. Otherwise, use 3.5 where possible.
Also, remove `cmake_minimum_required()` and `project()` calls from
individual cases where they are handled by `CMakeLists.txt`.
`CMakeFindBinUtils.cmake` sets `CMAKE_<TOOL>` variables that in
cross-compilation environments point to the toolchain specific
executables: e.g. `CMAKE_OBJCOPY` might point to
`<path_to_toolchain>/arm-poky-linux-gnueabi-objcopy`.
Pass this information to CPack.
Since macOS 12.0, the ``hdiutil udifrez`` and ``hdiutil udifderez``
commands to embed and extract resources in a disk image are deprecated.
The CPack DragNDrop Generator uses these to attach the SLA specified by
the `CPACK_RESOURCE_FILE_LICENSE` option. Since that option is shared
by multiple CPack generators, we cannot deprecate it. Instead, add an
explicit option to control the behavior. This will give projects a way
to package on future macOS versions that remove the commands.
In order to provide a long-term transition away from attaching SLAs to
disk images, update `cpack` to default this behavior to OFF. To retain
compatibility for CMake projects, teach the CPack module to default the
option to ON. Later a policy can be added to change the default.
Issue: #22978
Due to MCST LCC compiler identification is now changed to LCC,
there should be a way for old projects to still identify it as GNU,
as it was before.
This commits adds the policy:
CMP0129: Compiler id for MCST LCC compilers is now LCC, not GNU.
This policy controls such a behavior.
OLD behaivior is to treat LCC as GNU, NEW is to treat is as LCC.
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
"OS Elbrus" (OSL for short), a reference Linux distro for E2K (Elbrus)
platform may have broken dpkg-shlibdeps, that doesn't specify
dependencies correctly. In this case, the only reliable way is to
explicitly set dependencies of libc6 and lcc-libs, and then warn user
to let him know this list may be incomplete. This commit does that.
This fix has no effect on correctly working dpkg-shlibdeps, so when
this bug will be fixed in new versions of OSL, CPack will work as
expected with these distros.
There are several tests that run on systems that have rpm installed, but
they fail if there's no debugedit installed also. This commit makes
these tests being skipped in such case.
The generated path with the packages uses $CPACK_TOPLEVEL_TAG, which
by default is $CPACK_SYSTEM_NAME, thus the OS name.
To make the expected stderr match also non-Linux OSes, accept any
non-slash characters in place of "Linux", so it works also on other
Debian OSes (e.g. Debian/Hurd).
The RunCMake infrastructure's `*-stdout.txt` expected output files
interpret `\n` as a `\` and `n` rather than a newline. Use a literal
newline instead. Otherwise the cases that were trying to match any
configuration name via `[^\n]*` would fail on `RelWithDebInfo` because
it contains the letter `n`.
RPM 4.11.3 for el7 contains backported support for the RPM weak dep tags.
It only supports querying those tags, but rpmbuild can not make use of them.
Since CPack relies on rpmbuild --querytags to check for support, this
commit switches to rpm --suggests to check for support of weak
dependencies.
Fixes: #22350
Since commit c826745f5a (CPack/DEB: Do not crash when asked for debug
symbols when there are none, 2020-10-29, v3.20.0-rc1~461^2) the test
fails because CPackRPM warns about no sources in which to find debug
symbols. Add expected output for this case.
Format message content for `message(FATAL_ERROR)`.
Apply the change from commit c54c284de7 (Tests: Improve RunCMake.CPack*
test error formatting, 2021-04-22) to the `SOURCE_PACKAGE` script too.
Also fix a typo from commit f5d79dec53 (Tests: Cleanup CPack message when
files are expected and none are found, 2021-01-15, v3.20.0-rc1~89^2~22).
The new variable allows projects to define custom key=value pairs of
variables to be set in CPack cmake_install.cmake script invocations.
This allows install(SCRIPT|CODE) to be parameterized at runtime.
Merge use of SetFilterOption() into more abstract thread count
in cmArchiveWrite constructor.
libarchive defaulting of threads for threads == 0 seems to be
configuration dependent. Preemptively default thread count via
std::thread::hardware_concurrency().
Also allow negative values for the thread count in which case
the detected hardware concurrency is also used but the given
absolute thread count is used as an upper limit.
Scriplet tags should not be added to generated
spec files if scripts weren't provided as those
tags are otherwise present in generated rpm file
even if the script wasn't provided thereby
generating unneeded dependency on shell.
Fixes: #21345
Enabling CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE while
using rpm install or erase scripts resulted in
resulted missing scripts for non default components.
Fixes: #21974
Enabling CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE while
having an empty directory in non main component
resulted in packaging error that the directory
does not exist.
Fixes: #21951
When the user has the setgid bit is set on the parent directory of
the build directory, the setgid bit will be propagated throughout the
build tree. Most tests do not care about permissions as long as they
can read and write the files the need. The CPack tests, however, validate
that permissions match an expected set, and fail with the setgid bit set.
Explicitly set permissions on directories created in the CPackTestHelpers
to clear the setgid bit.
Signed-off-by: william.r.dieter <william.r.dieter@intel.com>
By default icx and icpx do not add build IDs when linking, so enable
the build ID to make the test pass.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
Previously, when looking for exactly one file and the number of files
was not one, the test printed out an error message saying that too many
files were found, then printing the list of files. However, 0 is not
1 and also not too many files.
To reduce confusion, this commit adds a different message when 0 files
are found and 1 is expected.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
Balazs Kosaras