GeezerVison is showing github.com — Fix autotools cmake package install for non-standard libdir by thetic · Pull Request #1881 · cpputest/cpputest
Conversation
thetic
commented
Mar 3, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
Fixes #1880.
Fixes #1563.
On Debian multiarch systems, --libdir is typically lib/x86_64-linux-gnu rather than lib. The pre-generated cmake package files assumed a fixed directory depth to compute the install prefix, breaking find_package(CppUTest) for any non-standard --libdir.
Rather than trying to detect the directory depth at cmake time, generate the cmake package files at install time with %%PREFIX%% and %%LIBDIR%% substituted directly from the autotools $(prefix) and $(libdir) make variables. This works correctly regardless of how deep libdir sits relative to the prefix.
While here, bring the autotools cmake install into parity with the CMake install: add missing cmake modules, use the CppUTest:: target namespace, and reorganize all package/install templates into a single pkg/ directory.
A new CI job (Autotools Custom prefix install) installs with a non-standard --libdir and verifies the result by building the examples against it with find_package.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
…tiarch)
The pre-generated cmake files in build/cmake_package_files/ hard-coded a
3-level directory traversal to find the install prefix. On Debian multiarch
systems (--libdir=lib/x86_64-linux-gnu) the files land one level deeper, so
the traversal resolved to /usr/lib instead of /usr, breaking every downstream
find_package(CppUTest) call.
Replace the three path-dependent files with *.autotools.in templates that use
%%PREFIX%% and %%LIBDIR%% placeholders. A new install-data-hook in Makefile.am
substitutes the real $(prefix) and $(libdir) at install time via sed, so the
generated files always contain correct absolute paths regardless of --libdir.
Also add an uninstall-local hook to clean up the generated files.
Fixes: cpputest#1880
Fixes: cpputest#1563
Move all cmake package config template files into a single cmake/package/
directory:
- CppUTestConfig.cmake.install.in (from repo root)
- CppUTestConfig.cmake.build.in (from repo root)
- CppUTestConfig.cmake.autotools.in (from build/cmake_package_files/)
- CppUTestTargets.cmake.autotools.in (from build/cmake_package_files/)
- CppUTestTargets-relwithdebinfo.cmake.autotools.in (from build/cmake_package_files/)
- CppUTestConfigVersion.cmake (from build/cmake_package_files/)
Also remove the stale pre-generated static cmake files from
build/cmake_package_files/ that are superseded by the autotools templates.
Update cmake/install.cmake and Makefile.am with the new paths.
Consolidate all packaging-related template files into a top-level pkg/
directory, replacing the cmake/package/ directory introduced in the
previous commit:
- pkg/CppUTestConfig.cmake.install.in
- pkg/CppUTestConfig.cmake.build.in
- pkg/CppUTestConfig.cmake.autotools.in
- pkg/CppUTestTargets.cmake.autotools.in
- pkg/CppUTestTargets-relwithdebinfo.cmake.autotools.in
- pkg/CppUTestConfigVersion.cmake
- pkg/cpputest.pc.in
Using a generic pkg/ directory rather than cmake/package/ better reflects
that the directory covers multiple packaging systems (cmake and pkg-config).
Update cmake/install.cmake, configure.ac, and Makefile.am accordingly.
Switch from include(cmake/install.cmake) to add_subdirectory(pkg), which
is more idiomatic CMake and lets pkg/CMakeLists.txt use relative paths for
files in the same directory instead of ${PROJECT_SOURCE_DIR}/pkg/ prefixes.
Update PROJECT_SOURCE_DIR-relative paths for files outside pkg/ (the cmake/
Modules and Scripts directories, and the project include/ directory).
The autotools install was missing two cmake modules needed for downstream
consumers to use cpputest_discover_tests():
- CppUTest.cmake and _CppUTestDiscovery.cmake were not listed in
cmakemodules_DATA in Makefile.am
- CppUTestConfig.cmake.autotools.in did not append the Modules directory
to CMAKE_MODULE_PATH, so include(CppUTest) would fail even if the files
were present
Both are present in the CMake install; bring the autotools install into
parity.
The autotools-installed cmake targets used bare names (CppUTest,
CppUTestExt) while the CMake install exports them with the CppUTest::
namespace (CppUTest::CppUTest, CppUTest::CppUTestExt). Downstream
consumers using target_link_libraries with the namespaced form would
silently get an error or unresolved target.
Update all three autotools cmake package templates to use the CppUTest::
namespace, matching what cmake's install(EXPORT ... NAMESPACE CppUTest::)
generates.
…tput
The templates were modelled on old cmake export file format. Rewrite them
to match the format cmake generates today:
- Use _cmake_ prefixed temporaries instead of _targetsDefined etc.
- Use 'IN LISTS "_cmake_import_check_files_for_${target}"' to safely
reference variable names containing :: without cmake parsing issues
- Use _cmake_import_check_targets/_cmake_import_check_files_for_* instead
of the old _IMPORT_CHECK_* names
- Update cmake_policy version range
- Add INTERFACE_LINK_LIBRARIES "CppUTest::CppUTest" to CppUTestExt so
that linking against CppUTest::CppUTestExt pulls in CppUTest::CppUTest
Adds an "Autotools Custom prefix install" matrix entry that:
- Configures with a non-standard --libdir depth (lib/x86_64-linux-gnu)
to exercise the install path computation in the cmake package files
- Installs directly (no DESTDIR) so cmake can consume the result
- Builds the examples against the installed package via find_package,
confirming that headers, libraries, and cmake modules are all found
correctly
Two new conditional steps are added to the autotools job:
- "Set install paths" computes INSTALL_PREFIX and INSTALL_LIBDIR from
the matrix install_prefix value, keeping the path defined once
- "Consume with CMake" runs the examples build against the install
coveralls
commented
Mar 3, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
|

coverage: 99.281%. remained the same
when pulling 8a685a1 on thetic:autocmake
into 79c066e on cpputest:master.
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
The build-tree CppUTestConfig.cmake was intended for find_package()
against the build directory, but was never wired up: there is no
export(PACKAGE) to register it and no export(CppUTestTargets) to
generate the targets file it tries to include. Modern cmake practice for
add_subdirectory/FetchContent is to use the namespaced targets directly.
The separate CppUTestTargets-relwithdebinfo.cmake.autotools.in file was
mimicking cmake's multi-configuration pattern, which doesn't apply to
autotools. Autotools produces a single build output, so IMPORTED_LOCATION
(no config suffix) is the correct cmake idiom and works for all
downstream build types.
Move the library locations directly into CppUTestTargets.cmake.autotools.in
and delete the now-unnecessary config-specific template.
…cmake package
The cmake install sets INTERFACE_COMPILE_OPTIONS on CppUTest::CppUTest to
force-include MemoryLeakDetectorForceInclude.h, wiring up leak detection
automatically for downstream cmake consumers. The autotools cmake package
was missing this, requiring consumers to add the force-include manually.
Add the same property to the autotools targets template, conditioned on
whether memory leak detection was enabled at configure time (it is also
implicitly disabled by --disable-std-c). The memory_leak_detection
configure variable is AC_SUBST'd so its value is baked into the Makefile
and passed to sed as a literal string at install time.
|
Thanks. Sorry for the late merge.
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assigned
Milestone
No milestone
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.
|