On 04.07.2016 22:15, Rémi Verschelde wrote: > 2016-07-04 19:23 GMT+02:00 Markus Koschany <apo@debian.org>: >> Hi all, >> >> I have packaged CaveExpress and CavePacker for Debian. Both are >> available in unstable now. [1] >> >> CaveExpress is a remake of the Amiga classic Ugh! [2] from the early >> 80ies whereas CavePacker is a Sokoban-like game. Both games share the >> same engine. There is even a third game in the pipeline for this engine, >> miniracer, but it is not finished yet. An interesting aspect of >> CaveExpress is that it is one of two games in the archive which use the >> Box2D physics engine. (numptyphysics being the other one) > > Hi Markus, > > Nice work! Hi Rémi and thank you! > I had looked at packaging CaveExpress and CavePacker for Mageia at > some time, but back then upstream used a dev version of SDL 2.0.4 (yet > unreleased) so I gave up. Later I tried again and had some issues with > the buildsystem that I did not feel like fighting. Yeah, I know that feeling. I also had some troubles with the build system but then I thought let's get the job done. > Now, since you have done all the packaging work for Debian, I started > looking into it again. > > I've pushed a couple patches upstream: > - https://github.com/mgerhardy/caveexpress/pull/93 (obsoletes your > man-page-spelling.patch) > - https://github.com/mgerhardy/caveexpress/pull/94 (fixes detecting > the system-wide glm) > - https://github.com/mgerhardy/caveexpress/pull/95 (fixes the CMake > issue you addressed in build.patch) Thanks. I wanted to do the same once caveexpress and cavepacker had been migrated to testing. As you have already noticed some of those patches can't be forwarded as is but I will discuss this with upstream later. > I think that some of your patches could benefit from being integrated > directly upstream: > - dataDir.patch: As I understand it allows to define > `PKGDATADIR=/usr/share/games` for all 2 (or 3) games without having to > recompile the whole engine to use > `PKGDATADIR=/usr/share/games/$gamename` for all of them. I guess > upstream might accept doing the necessary changes for us based on your > patch (probably not by merging the patch directly, as it would break > his current intended design, but adding a conditional behaviour should > be trivial). Exactly, that's the purpose of the dataDir patch. Running the build system twice to build both games was not really an option for me. > - desktop-file.patch: Had a look at implementing this properly for a > pull request, but it's not that trivial. The systems tries to be too > clever IMO. As it currently fills the `Description` tag of the desktop > file with a 3 lines long description from ABOUT.en (e.g. [3]), it's a > bit broken by design anyway. It would be good to open an issue > upstream and start discussing this to find the best alternative. Agreed. > I haven't finished my own package yet due to underlinking issues [4] > so I can't confirm it directly, but it looks to me that your patches > to use system-wide libraries are likely uneeded, as upstream provides > a (once again, IMO a bit too industrious) mechanism to detect system > libraries before reverting to embedded ones when not found. The main > issue with this system is that it relies on the CMakeLists.txt in the > various `src/libs/*`, and upstream seems to be wanting to move even > more detection stuff there, so `src/libs` can't be just `rm -rf`-ed. > That's also a topic that would be worth discussing with upstream > directly. I decided to delete src/libs completely and that's the reason why I had to find a way to properly detect the system libraries. Otherwise the buildsystem will still try to use SDL.h for example. I used cmake's FindPkgConfig module and that almost seemed to work perfectly. Some of Box2D's header files couldn't be found though, that's why I resorted to patching the include paths. Not really the perfect solution because normally cmake is smart enough to find the correct system paths but then it seemed good enough for the time being. I will try to find a better solution with upstream together. > > Hope this helps :) > > Cheers, Thanks! Markus
Attachment:
signature.asc
Description: OpenPGP digital signature