Project Soon

Platform Deployment

When developing your private program for your local platform, you might consider releasing it for other users to make use of it. While just releasing the code is the easiest route for the developer, it is either not feasible for the end user to install all the dependencies to run the program, or the developer do not want to release the source, but a compiled binary 1. In either case, a package containing dependencies and install instructions is to be processed and published. However, the platforms are many and the package managers are even more, so one needs to choose carefully to avoid spending too much time supporting obscure or obsolete package formats.

CPack

As I had previously made more use of cmake regarding testing, I wondered if it had another tool which could help me pack the resulting binaries: CPack 2. They have a bunch of generators which defines a set of variables in order to customize each package generated 3. The default will take all install targets and put them inside each package, but in my case it makes more sense to split up the binaries in respective package to make it easier for the user to pick what to install, something called Components.

NSIS vs Inno

The two most known package manager for Windows are NSIS 4 and Inno 5. Both have their ups and downs, and my initial decision was to use Inno, but when I found out that Inno had no easy way to be installed on Linux 6, I went for NSIS as it had both a package and all configs used to work inside wine 7. Both works in cmake, and are rather similar, but they generate different installers.

DEB vs RPM

Both DEB 8 and RPM 9 are trying to solve the same problem as Windows does with their installers, but as Windows does this by providing executable installers to let it put everything where it belongs, Linux does so by having a package manager and a list of repositories they will search and pull archives from to be installed. Each archive also comes with scripts to be run before or after installation. It is also possible to require dependencies to be installed, meaning the package manager will verify them being available, otherwise install them from the repository or from the archive itself if present. For me, I am only interested in adding more compatibility to reach more end users.

Archive

Some do not like to install their programs, or want the programs to be portable. Therefore providing a regular zip-archive makes it rather easy to use. Do note that while this could be the easy route for all users, it could be confusing for most.

Conclusion

There definitely are way more ways to release packages for any platform 101112, CPack even supports external ones. As previously mentioned, it is up to the developer to determine which platforms to release to, and ignore those that are not related to the project.


  1. There are several reasons to not release, either due to confidentiality for a proprietary library, or the source is not suitable for public exposition, to name a few. ↩︎

  2. https://cmake.org/cmake/help/latest/module/CPack.html ↩︎

  3. https://cmake.org/cmake/help/latest/manual/cpack-generators.7.html ↩︎

  4. https://nsis.sourceforge.io/Main_Page ↩︎

  5. https://jrsoftware.org/isinfo.php ↩︎

  6. https://gist.github.com/amake/3e7194e5e61d0e1850bba144797fd797 ↩︎

  7. https://www.winehq.org/ ↩︎

  8. https://en.wikipedia.org/wiki/Deb_(file_format) ↩︎

  9. http://ftp.rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html ↩︎

  10. https://brew.sh/ ↩︎

  11. https://dev.to/lexplt/making-your-project-available-through-homebrew-1ll5 ↩︎

  12. https://nixos.wiki/wiki/Packaging/Tutorial ↩︎