Bug 194997 - [patch] games/frotz Upgrade to 2.44p and add options for dfrotz and sound
Summary: [patch] games/frotz Upgrade to 2.44p and add options for dfrotz and sound
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Dmitry Marakasov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-13 19:36 UTC by bsdport
Modified: 2014-12-05 17:20 UTC (History)
2 users (show)

See Also:


Attachments
games/frotz: add OPTION_DUMB for dfrotz (1.41 KB, patch)
2014-11-13 19:36 UTC, bsdport
no flags Details | Diff
Upgrades games/frotz to 2.44p and adds DUMB/OSS options (3.13 KB, patch)
2014-11-13 23:12 UTC, bsdport
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description bsdport 2014-11-13 19:36:51 UTC
Created attachment 149383 [details]
games/frotz: add OPTION_DUMB for dfrotz

The existing games/frotz ports (2.43d from svn r371872) has a packaging list that includes (among others) the following files:

    bin/frotz
    man/man6/frotz.6.gz
    man/man6/dfrotz.6.gz
    share/doc/frotz/DUMB

Note that bin/dfrotz (a dumb terminal version) is *not* being installed even though it's man page is. (For most users the dumb terminal version isn't very useful, however it might be useful within a script or some such.)

The attached patch adds an OPTION_DUMB (default off) that adds/removes the following items from the packaging list:

    bin/dfrotz
    man/man6/dfrotz.6.gz
    share/doc/frotz/DUMB

The attached patch does not bump PORTREVISION since the only change for existing package users would be to remove the useless but harmless man page and doc file. However, this port gets updated so infrequently that it may be worth bumping it anyway.


As an alternative, the port could not bother with an option and just always install bin/dfrotz (or always leave it and the man page out).

Note: the patch doesn't bother to change the behaviour of package building, dfrotz is always built just like before (the whole package is very small and fast to build).

Thank you.
Comment 1 bsdport 2014-11-13 19:53:56 UTC
I just found a github repo for this (https://github.com/DavidGriffith/frotz) by the same author as the sourceforge page listed in the makefile that may have a more update-to-date version. I'll look into seeing if there is anything worth updating to (and if so you may wish to ignore this patch and wait and do the patch+upgrade together).
Comment 2 bsdport 2014-11-13 23:12:47 UTC
Created attachment 149385 [details]
Upgrades games/frotz to 2.44p and adds DUMB/OSS options

This newly attached patch obsoletes the previous one and additionally adds OPTION_OSS (default on) for sound support and upgrades to the the latest version of frotz now on github.

There hasn't been an "official" release in years, the last change on git was a few months ago and has an "internal" tag of "2.44pre" (for pre-release I assume) so the port is now PORTVERSION=2.44.p (FYI, one of the older branches on github does have the version bumped to 2.44 but it isn't finished/ready and the master branch has some fixes that for example make dfrotz useful).
Comment 3 John Marino freebsd_committer freebsd_triage 2014-11-14 13:08:34 UTC
CC'ing games@ about this unmaintained games port.

Actually I love Infocom stuff so if they don't care, I'll probably take a look.
Comment 4 Dmitry Marakasov freebsd_committer freebsd_triage 2014-11-23 17:35:33 UTC
This doesn't build with OSS disabled

-e option should be passed to make unconditionally, or MAKE_ARGS should be used. If MAKE_ENV is used, you don't need to specify CC and PREFIX there (framework does this for you). You also probably don't need to specify empty variables there as they're not redefined in upstream Makefile.

Adding make targets through MAKE_ARGS is not really correct. You need either something like

OSS_ALL_TARGET=soundcard.h

ALL_TARGET=    # empty

.include <bsd.port.options.mk>

ALL_TARGET+=   all

or better (as I'm not sure that the above way is parallel build safe)

.if ${PORT_OPTIONS:MOSS}
pre-build:
    cd ${WRKSRC} && ${DO_MAKE_BUILD} soundcard.h
.endif

Otherwise looks good. Won't you by the chance like to become maintainer of this port?
Comment 5 bsdport 2014-11-23 18:27:32 UTC
(In reply to Dmitry Marakasov from comment #4)
> This doesn't build with OSS disabled

It does for me, but that doesn't mean much :). I only tested it by doing
basic builds on my system with the various options enabled/disabled, not
by doing any of the more involved tests like using poudriere.

> [many little issues with the Makefile mentioned]

Thanks for taking the time to look at this.

My Makefile mistakes can be attributed to my being very much
out-of-touch with the current ports infrastructure (it's been years
since I did any significant change to a port Makefile) and that I
initially only wanted to add installation of bin/dfrotz and so just made
minimal changes to the existing Makefile (which already was doing a few
things not quite right IMO).

Since you're much more familar with the current ports infrastructure
than I am, I'd be grateful if you'd be willing to make the changes you
suggest rather than me attempting to incorporate them into a new patch
(without being able to test it beyond my system). I don't think there
is anything port specific that needs any special knowledge/testing with
frotz; it's one of those small things that if it compiles it'll work.

> Won't you by the chance like to become maintainer of this port?

I'd rather not make such a commitment. I've been the maintainer on some
ports in the past but stopped updating/using them and was eventually
removed.
Comment 6 Dmitry Marakasov freebsd_committer freebsd_triage 2014-11-25 00:45:20 UTC
> It does for me, but that doesn't mean much :)

Maybe that's because you're running pre-10.x which has gcc. Here on 10.x:

% env WITHOUT=OSS BATCH=1 make
===>  Building for frotz-2.44.p
gmake[1]: Entering directory '/usr/work/home/amdmi3/projects/freebsd/batchports-mem/games/frotz/work/DavidGriffith-frotz-3e4af2a'
gcc -O2  -o src/common/buffer.o -c src/common/buffer.c
gmake[1]: gcc: Command not found
Makefile:217: recipe for target 'src/common/buffer.o' failed

Though it would compile if I had gcc binary, not respecting ${CC} is not acceptable for a port.

> I only tested it by doing basic builds on my system

That is actually quite enough to find most problems. Especially as we now have staging support.

> My Makefile mistakes can be attributed to my being very much
out-of-touch with the current ports infrastructure

That is not a problem at all. Please don't take what I've written as a cavil - we just prefer to explain problems with people's submissions and make them fix these themselves. This approach bears fruit in long term, as submitters get more familiar with ports system, it's becomes easier for them to fix/update ports they're interested in, chances are higher that their following submissions are accepted right away, both their and committers' time is saved and more experienced and involved community is formed. Thus I urge you to try and fix your patch, but if you insist, I can just commit my fix.
Comment 7 Dmitry Marakasov freebsd_committer freebsd_triage 2014-12-05 17:20:19 UTC
Well, committing my version of changeset.
Comment 8 commit-hook freebsd_committer freebsd_triage 2014-12-05 17:20:21 UTC
A commit references this bug:

Author: amdmi3
Date: Fri Dec  5 17:19:57 UTC 2014
New revision: 374062
URL: https://svnweb.freebsd.org/changeset/ports/374062

Log:
  - Clarify LICENSE

  Also note that previous commit was related to:

  PR:		194997
  Submitted by:	bsdport@ddm.wox.org

Changes:
  head/games/frotz/Makefile