Omar Polo <op@openbsd.org> writes:
> la-ninpre <aaoth@aaoth.xyz> 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.
No comments:
Post a Comment