Skywalker13
commented
7 years ago Hi OdyX, I'm happy to see you here :smile:
Yes, I know that my CMakeLists file is not handling everything properly. That's the reason why I've added this comment in the main README file (planetblupi-dev repository):
https://github.com/blupi-games/planetblupi-dev#planet-blupi-development-bundle
If you are an official distribution packager, maybe you can directly use the https://github.com/blupi-games/planetblupi.git repository instead of this one but it's not the recommended way and in the case of a distribution, it needs some improvements in the CMakeLists.txt file (based on CMake).
I've written this CMakeLists file (in this repo) with one main goal; having a static and reproducible build for Linux, macOS and Windows (it was the challenge and I'm very happy because it works pretty fine on all platforms). Adding the support for dynamic linking was not my priority. My priority was releasing something cool and usable for everyone on every major platforms as soon as possible (I'm doing everything on my free-time; I'm not doing that via Epsitec SA).
But now that you are here, I'm sure that we can find a proper way to handle my static build (controlled via the CMakeLists file of the planetblupi-dev repository) and a dynamic build suitables for distributions like Debian (Fedora, etc, ...).
OdyX
Hi there,
although I understand the merits of an AppImage completely static build, there's still a lot of merit in being able to build an entirely dynamic Planet Blupi. I'm interested in publishing Planet Blupi to Debian, and static linking is not an option there (for plenty of good reasons).
The two only unavailable dependencies (
argaggandSDL_kitchensink) are quite easy to package, so I started with these:I'm happy to help where needed to get Planet Blupi built dynamically, with the aim in sight to be able to upload it to Debian, and let it benefit from wide exposure there, larger architectures support and automatic availability in multiple derivatives' repositories!