[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CaveExpress, CavePacker and more updates

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.


> 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,



Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: