Bug#1147390: dh-fortran: dh_fortran_cmake does not install or rewrite CMake target files (process_file() is an unimplemented stub)

Igor Luppi igor.luppi at canonical.com
Fri Sep 11 15:02:00 BST 2026


Package: dh-fortran
Version: 0.85
Severity: normal
X-Debbugs-Cc: mckinstry at debian.org, talha.can.havadar at canonical.com

Dear Maintainer,

dh_fortran_cmake finds CMake config/target files matching a package's
debian/<pkg>.fortran-cmake glob, but never actually installs or
rewrites them into the binary package. The files are silently dropped:
dh_missing does not flag them as missing (they are recorded as
"handled" before processing), but they simply never appear in the
built .deb.

Root cause: CMakeFileHelper.process_file() in dhfortran/cmake.py is an
unimplemented stub:

    def process_file(self, pkg, cmake_file, target_pkg, target_dest=None):
        cli.debug_print(
            f"process_file [lib]  name {cmake_file} {target_pkg}
{target_dest}"
        )
        ...

Unlike ModFileHelper.process_file() (dhfortran/module.py), which
actually calls dh.install_dir() and self.doit(["cp", ...]) to copy the
matched file, CMakeFileHelper.process_file() has no body beyond the
debug print and the Ellipsis placeholder.

A second, related bug: even if process_file() were implemented to copy
the file, the module also defines a rewrite_cmake() helper intended to
patch IMPORTED_LOCATION / INTERFACE_INCLUDE_DIRECTORIES references
inside the CMake target file to point at wherever dh_fortran_lib /
dh_fortran_mod actually relocated the corresponding .a/.mod files (the
docstring and inline comments describe exactly this: "rename
references to Fortran libs", with example sed substitutions for
${_IMPORT_PREFIX}/lib, /include, and /module). But rewrite_cmake()
itself is also broken:

    with open(oldname, "r") as f:
        with open(newname, "w") as n:
            n.write(f.read)

f.read is missing its call parentheses -- this writes the bound
method object's repr instead of the file's contents, and the function
appears to never be called from anywhere in the current codebase
regardless.

Impact: any package that declares a debian/<pkg>.fortran-cmake file
ends up shipping no CMake config at all in the location dh-fortran
would place it, and any package that DOES install its own CMake
config verbatim (bypassing dh_fortran_cmake) ends up with
IMPORTED_LOCATION / INTERFACE_INCLUDE_DIRECTORIES entries still
pointing at the pre-relocation paths, since nothing rewrites them to
match dh_fortran_lib's/dh_fortran_mod's per-compiler destinations.
find_package(<pkg>) then either finds nothing, or finds a config
referencing files that don't exist.

This was hit packaging hipfort 10.0.0 for Ubuntu: we ended up working
around it by disabling hipfort's own multitoolchain CMake layout
entirely (so the CMake config lands at the plain, non-relocated
per-arch path that find_package resolves natively) and installing the
CMake config/target files and static libraries via a plain
debian/<pkg>.install line instead of routing them through
dh_fortran_cmake/dh_fortran_lib. See the packaging for reference (Ubuntu
git, branch hipfort-10.0 -- not yet pushed to Salsa):

  https://git.launchpad.net/~bullwinkle-team/ubuntu/+source/hipfort
  debian/patches/0001-disable-multitoolchain-layout-by-default.patch
  debian/rules (see the comment block above override_dh_auto_install)

To reproduce in isolation: any Fortran package using CMake with a
debian/<pkg>.fortran-cmake config file listing a glob that matches
real files in debian/tmp at build time. After the build,
debian/<pkg>/ will not contain those files under the expected
/usr/lib/<multiarch>/fortran/cmake/<target>/ destination (or anywhere
else) -- dh_fortran_cmake's log shows no install_dir/doit lines for
them at all, only the "source=... binary packages=..." header line.

Thank you for maintaining dh-fortran -- it's a great addition to
Debian's Fortran packaging tooling once this is fixed.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64



Igor Luppi

Software Engineer

Email:

igor.luppi at canonical.com

Location:

Brazil


<https://canonical.com/>

canonical.com

ubuntu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20260911/ce16f0f9/attachment-0001.htm>


More information about the debian-science-maintainers mailing list