Re: NEW: games/cromagrally

On 2024/01/30 10:26:05 -0500, Thomas Frohwein <tfrohwein@fastmail.com> wrote:
> On Tue, Jan 30, 2024 at 01:46:49AM -0600, izder456 wrote:
> >
> > Hey ports@ w//ckies,
> >
> > If it wasn't clear enough already, I love these games. Given that (in
> > theory) OpenBSD/macppc has 3D-Acceleration on the r128(4) driver, it
> > would be wonderful to run this on an era-accurate PPC iMac.
> >
> > TL;DR:
> > I want to import my port of CroMagRally, which is yet another Pangea
> > Software title originally for the PPC macs. I think it's been three
> > I've submitted now... :)
> >
> > the 3.0.0 GH_RELASE has a bug with byteswapping terrain textures, so i
> > just pointed this port against the latest commit hash. unsure if I can
> > still refer to this as "3.0.0", thoughts?
> >
> > As normal, I did some patchwork to allow the binary to be ran from
> > anywhere so core files can be properly dumped again. (referencing
> > Omar's patch of Nanosaur2)
> >
> > Attached is the port, OK to import?
> >
> > --
> > ----
> > -iz
>
> TLDR:
> Thanks, looks generally good, builds and runs. Now supertuxcart has
> some competition. Attached port with small modifications, ok thfr@.
>
> Longer reply... Regarding the versioning:
>
> See packages-specs(7) for guidance on picking a version. There isn't a
> 100% established way when there are upstream improvements without a new
> release. The one aspect that seems certain is to not ignore the last
> (or next) release version number. After that, there are the following
> options up for debate from what I have seen and what packages-specs(2)
> offers:
>
> 1. Add patch-level to version number (3.0.0pl0).
>
> 2. Add REVISION (3.0.0p0).
>
> 3. Treat it as a precursor to the next release (e.g. 3.0.1alpha0).
>
> The risk with 1 and 3 is that it could collide with upstream's
> numbering of future versions. Option 2 goes a bit against the grain
> that REVISION is usually for when the port is changed (change in
> build options etc.).
>
> I am personally favor of option 1, but open to hear if there are
> arguments for a different default approach to this common situation. I
> have updated cromagrally accordingly and attached it.
>
> I replaced your Makefile alignment with tabs as this is most commonly
> used in ports in my experience (VARIABLE<space>=<tabs>value).

ok op@ with NO_TEST removed (it is needed for when `make test' would
fail due to the absence of a regress suite, in this case it just prints
'no tests', so it is fine) and with libsamplerate removed


Thanks,

Omar Polo

--- Makefile.orig Tue Jan 30 18:25:04 2024
+++ Makefile Tue Jan 30 18:25:31 2024
@@ -24,13 +24,9 @@

MODULES = devel/cmake

-BUILD_DEPENDS = audio/libsamplerate
LIB_DEPENDS = devel/sdl2
-RUN_DEPENDS = audio/libsamplerate \
- devel/desktop-file-utils \
+RUN_DEPENDS = devel/desktop-file-utils \
x11/gtk+4,-guic
-
-NO_TEST = Yes

CFLAGS += -I${X11BASE}/include
CXXFLAGS += -I${X11BASE}/include