On 2024/02/15 14:49:30 -0500, Jag Talon <jag@aangat.lahat.computer> wrote:
> >   - could use DIST_TUPLE (+ make makesum)
> 
> Good to know about this. I copy-pasted from dhewm3 instead of looking at 
> the template which has DIST_TUPLE.

DIST_TUPLE is still relatively new, so not many port are already using
it.  However, when it makes sense, I think it's a better than GH_* (if
anything, because it saves two lines ;-)

> >   - why set COMPILER?  Haven't tested with gcc4, but a quick scan didn't
> >     reveal something that it shouldn't handle.  Maybe there's a chance
> >     it'll work :)
> 
> I was filling out the template and now that I'm reading again it looks 
> like COMPILER is only for C++? I guess I didn't really understand that 
> and I just filled it out.

not exactly, it's silghtly more tricky.  don't want to sound like a
RTFM, but bsd.port.mk(5) has a better description for COMPILER and
COMPILER_LANGS that I could ever give :)

(in short, I think this has some chances of working with base-gcc so
let's try.  If it doesn't, then your COMPILER/COMPILER_LANGS was
correct.)

> >   - sdl2 and sdl2-image are only LIB_DEPENDS, no need to set them
> >     BUILD_DEPENDS
> 
> What's the difference between LIB_DEPENDS and BUILD_DEPENDS and WANTLIB? 
> Sorry I got confused about that.

BUILD_DEPENDS is used to track the dependencies needed to build the
thing, like build tools etc.  In this case, only bash and vim (xxd) are
build depends.

When a port provides a library it is listed in LIB_DEPENDS, since it's
both a BUILD_DEPENDS and a RUN_DEPENDs.  But it's also a bit more
special.

Libraries needed by a port are tracked since the resulting package may
need to be reinstalled when a library it depends on is updated, even if
the package itself didn't change the version.  (thats why, after a
popular library, maybe even libc, is 'bumped' a few days later pkg_add
will reinstall almost all packages)

WANTLIB lists the exact libraries names the binaries included in this
port link to, and contains both stuff from base and from ports.

Finding the value for LIB_DEPENDS and WANTLIB can be aid by `make
port-lib-depends-check', which will report all the missing LIB_DEPENDS
(unreachable - pkglocate can be used to know the package name from the
libraries reported by make) and gives you some WANTLIB lines that can be
copy-pasted in the makefile.

Some edge case (like libraries installed in non-default paths or
libraries linked statically) may need some manual handling, but for the
vast majority of ports it's quite simple and automatic.

> >   - it still needs bash as build depends
> >   - we can simplify do-build by using ALL_TARGET
> 
> Good to know thank you I didn't know about this! I'm not familiar with C 
> build systems so still learning!

in a nutsell, `make foo && make bar && make baz` is equivalent to `make
foo bar baz` (at least with one job, using -j may invalidate this
assumption.)

Also, if you really have to roll your own do-build, starting from the
default one is reccommended.  (it's documented in bsd.port.mk(5), see the
build description -- `:t build ENTER' when reading the manpage)

> >   - in the readme suggesting to run firefox /usr/local/share/... is not
> >     going to work: most browsers can only read /tmp/ and ~/Downloads by
> >     default on OpenBSD.  I'm personally using python3 -m http.server as a
> >     quick way to access these HTML files, not sure we can suggest it in
> >     the README however...  Not a huge deal however.
> 
> I think this works, actually! /usr/local/share is read-only in 
> /etc/firefox/unveil.main and /etc/iridium/unveil.main by default so 
> people should be able to read the files there!

lol!  well, it's a TIL for me!  I actually never realised this, i've
always used python to start a local http server for e.g. browsing
postgresql docs.  There's always something to learn :)

> > I'm attaching a diff against your makefile and an updated tarball with
> > the other patches.  With this it builds fine and tests are fully
> > passing.  I can also run the program and some of the installed examples.
> > Still have to really dive in it however :)
> 
> Thank you so much again I'm learning a lot here.

thank you for porting it :)

I've come across decker a few months ago and wanted to play with it, but
never actually found the time.