[snip]
Post by tristanPost by Harriet BazleyIt's been a LONG time since the last port.
Sorry! See below for excuses. :)
[snip]
Post by tristanDoes anyone know the current mechanisms for porting to RISC OS.
I did it years ago but things have changed (ISTR Musus Umbra was the
main RISC OS guy...)
Well, I know, because I've done pretty much all the recent(ish) ones. :)
It's a pretty straightforward process except where major
structural changes have taken place[1]. It goes like this :
1. Have a working C compiler setup, either new Norcroft, GCC, or old
Norcroft with StubsG. You also need DeskLib version 2.50 or above.
2. Take the source zip or tarball. If it is a tar.gz you try to
remember the correct way to invoke the commands on RISC OS, or else
dearchive it on your Linux machine and copy it across.
3. Take the angband-kit archive which I keep forgetting to zip up
and put on my ports page, and use the various tools to put the source
files into the correct directory structure and fiddle with
line-endings where it matters.
4. If you're lucky, I've done a port of the given variant since I last
changed the frontend code (which is a while ago now), and have sent
a working Makefile and main-ros.c to the maintainer of that variant,
so all you have to do is check that there are no new files to add to
the Makefile. You can then proceed to step 7.
5. If you're unlucky, main-ros.c needs updating to the latest version
(which should be in the angband-kit archive). The problem
here is that there are several different forms of various functions
and macros across the different variants, and we (well, mostly Musus)
have tried to maintain a single frontend file with #defines to pick
which version of the interfaces to use. There is a whole raft of
#defines to choose from at the top of the main-ros.c file, depending
on whether a variant supports bigscreen (not Sang bigscreen, the
normal sort), whether functions like my_strcpy are defined elsewhere
in the source, how the memory allocation functions work, etc.
I tend to deal with this by keeping a copy of the main-ros.c or
main-acn.c which came in the source archive, and referring to that
for settings which should work, filling in the others by hopping
around in the source.
6. Next is getting a working makefile together. I supply a template
Makefile in the angband-kit, which works for the Lua-enabled variants
(Angband, Zangband and ToME I think). That makefile is for GNU make
and supports both Norcroft and GCC compilers. You'll need to edit
the list of object files to match those actually needed by the
variant you're compiling, and may also want to remove or comment out
the Lua sections, depending.
7. Run "make -f Makefile.ros" in the correct directory, with a 15000k
wimpslot or thereabouts. You *will* get warnings with almost every
variant. Angband may have a relatively clean codebase but it is not
perfect, and Norcroft in particular picks up on possible problems
other compilers ignore. The trick is working out which of these
should be fixed and which shouldn't. I tend to try and fix as many
as possible, or at least to point all of the fixable ones out to the
maintainers. This is for two reasons: I hate ignoring
sensible warnings on code as they are there for a reason and I worry
that if the code is allowed to degenerate away from perfect
portability it will eventually be too much trouble to compile on
RISC OS or any other minority OS. Thanks to the maintainers of the
various variants for putting up with my correspondence over these
relatively trivial matters.
8. All being well, you now have a shiny new executable. If compilation
has not completed, you'll have to go back and tweak things again
(particularly in main-ros.c - I normally compile that file a dozen
times before I get all the settings right :)
9. Now you have to package it into an application so you can run it.
This is where I always screw up - missing out files, including huge
files which are no use on RISC OS, all sorts of things. :)
You should be able to take the bare Fooband skeleton from the
angband-kit and copy in the executable and the lib directory from
the source archive. Then you edit the !Variant file to have the
right name (the same name you set in the main-ros file), filetype and
wimpslot.
You should now be able to run the game. I tend to spend a little
time running around and being killed by various things in an attempt
to detect bugs. I'm not sure I've ever found one that way though.
10. There are instructions in the kit for making a manifest file and
then packaging up the program to distribute. I normally write a
few lines in one of the many readmes to outline any changes or
isues, and give a contact email, then I upload it to my webspace and
update my ports page. I don't know what other people would want
to do with theirs, but I'd be happy to update my page to point to
the latest version of any given variant, and space allowing I could
even host the archives (there's always drobe's webspace to fall back
on if I run out of space with NTL). Then there's a post on here to
tell people about it. I've been known to tell Acorn Arcade, drobe
and comp.sys.acorn.games about them as well.
It sounds horrendous if you've never ported anything before, but it
actually isn't that bad compared to most. The things which trip you up
are (almost) always in the same place, and you learn the right places to
look to solve problems fairly quickly.
If you do email known working versions of main-ros.c and Makefile.ros to
the maintainers, it makes it much easier next time. My problem with
that tends to be that I wait for any bugs to shake out before sending
them, and by the time I could be fairly sure they were bug free I just
forget all about it.
Post by tristanI have access to RISC OS machines (RiscPC and Iyonix) so may be able
to do some compilations.
Well, I'd be grateful. If I don't have spare time I tend to let the
compiliations slide and then spend a couple of days a year just
compiling up the latest versions. Combine that with doing less RISC OS
stuff generally in the last year or so, and my best monitor recently
dying, all help will be gratefully received.
I *will* upload a new version of the angband-kit to my ports website at
http://ajps.mine.nu/angband/ports in the next few days, and am always
willing to talk to people by email or IRC [2] about any issues that come
up, or just to coordinate efforts so that two people don't waste time
compiling the same variant.
[1] ToME3, for instance, is probably best attempted as a fresh port
using the various Unix-compatible tools and libraries we have around
now, thanks to the GCC porting team and the UPP.
[2] I'm ajps on IRCNet (uk.ircnet.org), and am always in #playpen. I'm
also on WorldIRC (irc.worldirc.org) from time to time, though your
best bet there is to /msg me.
--
Antony Sidwell.