Add opt-in CPack support for RPM and DEB packaging - #3904
Open
jameshickman wants to merge 4 commits into
Open
Conversation
`cpack -G RPM` previously produced packages named aws-sdk-cpp-Devel /
-Development / -Runtime / -Unspecified with no inter-package Requires --
none of the per-component naming or dependency config in the macros took
effect. Verified end-to-end: cpack now generates aws-sdk-cpp-{core,
core-devel, crt, crt-devel} with correct Requires (system devel libs,
cross-package version-pinned deps, AUTOREQ for shared libs).
CPackComponents.cmake:
- Uppercase component name on the LHS of CPACK_RPM/DEBIAN_<COMPONENT>_*
sets (CPack uppercases before lookup, so lowercase names were ignored)
- Drop \${CPACK_PACKAGE_VERSION} backslash escape so CMake substitutes
the version at configure time (CPack does not re-expand ${...} -- RPM
uses %{...} for macros, not ${...})
- Force macro-arg dereference via "${GROUP_NAME}" in if() -- a bare
GROUP_NAME inside macro() is a variable lookup, not a substitution,
so the non-core branch was running for core too and overwriting the
standalone CORE-DEVEL_PACKAGE_REQUIRES
- Switch devel-package dep target between runtime and -static based on
BUILD_SHARED_LIBS so static-only builds don't depend on a runtime
package that was never produced
- Drop hardcoded distro-specific runtime package names (libcurl vs curl,
libssl3 vs libssl1.1); rely on AUTOREQ/SHLIBDEPS for runtime deps
- include(CPackComponent) so cpack_add_component_group works -- this
file runs before include(CPack) loads the helper
- Route aws-crt-cpp's Runtime/Development install components to
aws-sdk-cpp-crt[-devel] rpm/deb names and add the crt-devel cross-dep
on core-devel
CPackConfig.cmake:
- CPACK_COMPONENTS_GROUPING IGNORE (was ONE_PER_GROUP, which collapsed
runtime+devel into a single package and bypassed all per-component
name/Requires variables)
CMakeLists.txt:
- Move include(ServiceGroupMapping.cmake) before add_sdks() so
get_service_group_component is defined when each service's
setup_install/do_packaging runs -- otherwise every install fell
through to "Unspecified"
- Default CMAKE_INSTALL_DEFAULT_COMPONENT_NAME to "Development" around
add_subdirectory(crt/aws-crt-cpp) so the CRT submodules that install
without an explicit COMPONENT (aws-c-http, aws-c-compression headers)
merge into the crt-devel package instead of producing a stray rpm
setup_cmake_find_module.cmake:
- Tag installs with COMPONENT core-devel (was landing in Unspecified)
- Exclude build-only files (CPackConfig.cmake, CPackComponents.cmake,
ServiceGroupMapping.cmake, rpm-scripts/, deb-scripts/) from the bulk
cmake/ directory install so they don't ship to consumers
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Four install() calls picked up a COMPONENT argument unconditionally, so they changed behavior even with ENABLE_CPACK_PACKAGING=OFF: the three find_package(AWSSDK) config installs moved from CPack's implicit "Unspecified" bucket to "core-devel", and the exported targets file moved from "Unspecified" to "Devel". A plain `make install` was unaffected, but component-scoped installs (cmake --install --component ...) were not. Wrap those in a variable that expands to nothing when the option is off, so the option genuinely gates the whole feature. The EXCLUDE patterns on the bulk cmake/ directory install are left unconditional on purpose: they only match files this branch adds, so keeping them always-on leaves the installed tree identical to before rather than shipping build-only scaffolding to consumers. Verified by configuring core with the four modified files reverted to upstream and again with ENABLE_CPACK_PACKAGING=OFF: the generated cmake_install.cmake files are identical apart from those EXCLUDEs. With the option ON, core-devel and core-runtime components are still assigned. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YCSRkLxHYetVoe421e5fha
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue #, if available: #843 (also relevant to #1888)
Description of changes:
Adds opt-in CPack support for building RPM and DEB packages of the SDK, split into per-service-group components rather than one monolithic package.
Everything is behind a new
ENABLE_CPACK_PACKAGINGoption that defaults toOFF.I verified what "off" actually means rather than assuming it: I configured the
corebuild twice — once with the four modified files reverted to their upstream contents, and once with them as they are on this branch and the optionOFF— then diffed every generatedcmake_install.cmake. They are identical except for one deliberate difference, described below. Noinclude(CPack), no changed install components, no new targets.The one difference with the option
OFF: the bulkcmake/directory install gains fiveEXCLUDEpatterns. Those patterns only ever match files this PR adds (CPackConfig.cmake,CPackComponents.cmake,ServiceGroupMapping.cmake,rpm-scripts/,deb-scripts/). They are unconditional on purpose — without them, a packaging-disabled build would start shipping this branch's build-only scaffolding into consumers'lib/cmake/AWSSDK. Keeping them always-on is what makes the installed tree byte-for-byte identical to today's.What it produces
With
-DENABLE_CPACK_PACKAGING=ON,cpack -G RPM/-G DEBgenerate separate runtime and-develpackages per service group (e.g.aws-sdk-cpp-core,aws-sdk-cpp-core-devel,aws-sdk-cpp-crt,aws-sdk-cpp-crt-devel), with:-devel→ matching runtime,crt-devel→core-devel)AUTOREQ/SHLIBDEPSinstead of hardcoded distro package names (avoids thelibcurlvscurl,libssl3vslibssl1.1split across distros)-develdependency target switched between the runtime and-staticpackage based onBUILD_SHARED_LIBS, so static-only builds don't depend on a runtime package that was never producedNew files
cmake/CPackConfig.cmake,cmake/CPackComponents.cmake— CPack setup and per-component naming/dependency configcmake/ServiceGroupMapping.cmake— maps the ~400 generated service clients into installable groupscmake/rpm-scripts/,cmake/deb-scripts/— post-install/post-remove ldconfig scriptletsscripts/build-packages.sh— convenience wrapperdocs/PACKAGING.md— build/install/consume documentationModified files
CMakeLists.txt— theENABLE_CPACK_PACKAGINGoption and three gated hookscmake/setup_cmake_find_module.cmake— tag config-module installs with thecore-develcomponent, and exclude build-only files from the bulkcmake/install so they aren't shipped to consumerscmake/utilities.cmake,src/aws-cpp-sdk-core/CMakeLists.txt— component routing on existing install rulesNo generated client code is touched, and no changes were made under
code-generation/.Scope / limitations
LEGACY_BUILDpath (the current default). The-DLEGACY_BUILD=OFFmodern-CMake path is not covered — happy to extend it if you'd prefer that first.Check all that applies:
.rpm/.debartifacts. Verified manually on Linux: (a) the configure-time A/B diff of generated install rules described above, confirming the option genuinely gates the feature; (b) with the optionON,cpack -G RPMemits the expected per-component package set, withrpm -qp --requires/dpkg-deb --infoshowing correct inter-packageRequires/Dependsand autodetected shared-library deps. Glad to add a CI job that builds packages and asserts on the output if you'd like that as part of this PR.docs/PACKAGING.md.Check which platforms you have built SDK on to verify the correctness of this PR.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.