{"id":1051,"date":"2025-10-03T21:53:58","date_gmt":"2025-10-03T19:53:58","guid":{"rendered":"https:\/\/seriyps.com\/blog\/?p=1051"},"modified":"2025-11-15T22:51:35","modified_gmt":"2025-11-15T21:51:35","slug":"making-a-deb-package-for-cmake-c-project","status":"publish","type":"post","link":"https:\/\/seriyps.com\/blog\/2025\/10\/03\/making-a-deb-package-for-cmake-c-project\/","title":{"rendered":"Making a .deb package for CMake C\/C++ project"},"content":{"rendered":"\n

Each time I need to package some software as .deb, I am not able to do it in one go. Because it is always a quite complex procedure that requires quite a lot of knowledge and context and you have to learn a lot of tools (million of debhelper tools, dpkg, debuild etc). It is designed to be comfortable for “large-scale” debian package maintainers who maintain a lot of packages for the Debian project, but is not very friendly for “indie” developers working on their own projects. And the process may vary a lot depending on what kind of software you need to package (what language, is it a library or shell tool or GUI etc). Also it strictly recommends that debian packaging files are stored separately from the software repo which might be somewhat inconvenient for small projects. We are going to include the debian<\/code> directory into the project.<\/p>\n\n\n\n\n\n\n\n

So in this article we are going to build a very specific kind of package: binary package for CMake project. However we are going to cross-compile it for arm64 from amd64 machine.<\/p>\n\n\n\n

The application is PixelPilot<\/a>.<\/p>\n\n\n\n

Preparation<\/h2>\n\n\n\n

For the reference: official Debian packaging manual<\/a>.<\/p>\n\n\n\n

Let’s clone the source code<\/p>\n\n\n\n

git clone https:\/\/github.com\/OpenIPC\/PixelPilot_rk.git<\/code><\/pre>\n\n\n\n
The app repo is named using camel-case notation, so let’s assume that our DEB package going to be named pixelpilot-rk<\/code>.<\/p>\n\n\n\n
And let’s assume we are building the git tag 1.3.0 and will build a DEB package with version 1.3.0. Let’s define a variable for that<\/p>\n\n\n\n
export PKG_VERSION=1.3.0<\/code><\/pre>\n\n\n\n
If the project we are building doesn’t have proper versioning culture, we can use artificial version based on the last commit date and sha:<\/p>\n\n\n\n
PKG_VERSION_PREFIX=1.0.0\nPKG_VERSION=`git log --date=format:%Y%m%d --pretty=${PKG_VERSION_PREFIX}~git%cd.%h | head -n 1`<\/code><\/pre>\n\n\n\n
It would generate a version number like 1.0.0~git20250607.2ec19e1<\/code>, where the commit date would guarantee that it would be increasing over time.<\/p>\n\n\n\n
Generate the template files<\/h2>\n\n\n\n
We can ofcourse create all the files by hand, however there are quite a lot of them and some have rather complex structure. So, let’s use the dh_make<\/code> tool from debhelper<\/code> package:<\/p>\n\n\n\n
cd PixelPilot_rk\ndh_make --packagename pixelpilot-rk_${PKG_VERSION} --single<\/code><\/pre>\n\n\n\n
This will generate the debian\/<\/code> directory with a lot of files in it (most have .ex extension because they are examples and if you plan to use it, the .ex extension needs to be removed). Most of those files have names that follow a special convention and debhelper tools would look for those files and change the way the final package is built depending on the existance of various files and their contents. Some of the files are not generated and we’d need to create them from scratch.<\/p>\n\n\n\n