Omar Polo <[email protected]> writes: > la-ninpre <[email protected]> writes: > >> Hi, >> I ported the game Sonic Robo Blast 2 to OpenBSD and also Game >> Music >> Emu library that is required for music in this game to work. >> >> It would be nice if someone can test it. I've already run it >> successfully on 7.0-current and also another person tried it on >> i386 architecture. >> >> I was unsure about distribution of game assets, so i followed >> approach >> similar to other game ports: only game binary is distributed and >> user >> is supposed to download and install game assets by themselves. >> >> Anyway, all input is welcome! >> >> Regards, >> Leo. > > Hello, > > regarding libgme: > > the ports looks fine. I'd only tweak the order of the variables as per > Makefile.template (i.e. DISTNAME at the top, the SHLIBS, CATEGORIES, > HOMEPAGE...). SEPARATE_BUILD is already implied by the use of cmake; > CONFIGURE_ARGS is usually lay down a bit differently and I can't find > them grepping the sources (and cmake warns about unused defines); > CMAKE_INSTALL_PREFIX is not needed. The code is (seems) C++11, so let's > add a comment about that before the COMPILER line and drop base-gcc from > the list. I'd add a NO_TEST=Yes since there aren't any tests. > > Otherwise builds fine on amd64. > > I'd drop the "Use CMake to build" from pkg/DESCR, as I don't think the > build system used is an important info for DESCR. > > > regarding srb2: > > ports looks fine too, but most of the previous point applies here as > well. In addition, DISTNAME is not needed when using GH_TAGNAME (it's > only when you need to use GH_COMMIT otherwise the tarball ends up with a > weird name.) CMAKE_BUILD_TYPE is already taken care of by modcmake, as > well as CMAKE_INSTALL_PREFIX. I'd explicitly disable ccache for cmake, > that's already taken care by the port infrastructure. The port is a C > one and since COMPILER is the default I guess we can drop it. We can > always revisit this if it fails the builds on gcc arches. > > We usually don't hardcode /usr/local, so in patch-src_sdl_i_system_c I > went with ${PREFIX} + SUBST_CMD in pre-configure. We also need to tweak > PATCHORIG otherwise `make update-patches' picks up stuff that isn't ours. > > Regarding the assets: IANAL but I see that other distributions packages > those too (either in the srb2 package or in a -data subpackage.) There > is a file with the thirdy parties licenses[0] and it list all "OKish" > licenses. With the assets the package weight a bit more, it's around > 180M, maybe we could split it. (and dropped the README at this point) > > Attaching the updated tarballs as per previous notes. I've only opened > the menu (no time to play today :/) but it's OK op@ to import if someone > does some testing. I'll do some proper testing in the following days ;)
I was probably a little too optimistic ;-) la-ninpre noted off-list that now that we're fetching the assets there's no need to list the hashes in assets/CMakeList.txt and that we can avoid rm(1)'ing files in post-extract by tweaking the EXTRACT_CASES: we're only interested in the .pk3 and .dta files, it should save a bit of space during builds I guess. I forgot to sort WANTLIB in previous submission and when tweaking patch-src_sdl_i_system_c I haven't noticed that it was adding HOME/.local/share/SRB2: upstream doesn't do that and I don't see any reason to add an extra search path. I tried to play the game but it always segfaults, either in the first level or in the tutorial, after a couple of seconds. It doesn't leave any core files around (it seems to trap SIGSEGV) and it quits with a 'got signal 5' (which is SIGTRAP) when started from egdb. FWIW, I'm running on amdgpu. Probably not too hard to debug, but I don't have time for that atm. Attaching an updated tarball with the above point addressed and DEBUG_PACKAGES set, should aid the debugging.
srb2.tar.gz
Description: Binary data
-- Please keep replies on the mailing list.
