Post by Leon MarrickOK. Got a collection of helpful bug reports and also some posts that
indicate I need to provide better documentation on compiling,
porting and such. Let's see if this post helps.
It does, indeed, but is not quite enough by itself.
Post by Leon MarrickThere are only two ports that I personally keep up-to-date. The
first is the Windows port, intended to serve everyone with a Windows
PC updated in the last decade. The second is the cross-platform SDL
(Simple DirectMedia Layer) port; SDL runs on a wide variety of
graphical platforms, but I have actually compiled and tested this
port only on Linux and Windows.
This is fine, or at least tolerable; the problem was that it was not
clear, and the natural expectation is that all ports made available as
part of a release will be up to date and functioning with the rest of
the release. (Though admittedly I may be slightly spoiled by the MPlayer
project, which is unusual in that even the latest mid-development code
is intended to be functioning and stable at almost all times.)
Post by Leon MarrickI do not guarantee that any other port will be up to date. You
should not try them unless the above two ports cannot be made to work
correctly on your system. I'm always grateful for additional and
updated ports, and will post them on the official website, but future
changes in the underlying game interface code can't help but break
compatibility again in the future. Sorry about that. :-/
Entirely understandable. The problem could be somewhat rectified by
documenting what the changes in the underlying interface code are, so
that someone else could more easily keep the other ports up to date, but
I do understand that documenting even a program much less its code is in
some ways a much bigger task than actually writing it - and would a: be
less fun and b: take time away from development, in any case. (Also see
below.)
Post by Leon Marrick- Only the SDL port is fully up to date. Getting it to run on my
1) Updating to SDL 1.2 (don't try earlier versions) and SDL_ttf (also
SDL_mixer if you want sound and music).
2) typing "make -f makefile.sdl".
Now that I've actually installed SDL_ttf (a library which I did not even
realize existed and which does not seem to be mentioned in the included
build documentation), it does compile and run, although only when both
named 'sangband.exe' *and* in a particular directory (the one to which
it is moved by the last step of that make command).
I have, if I'm not mistaken, configured it to run from any location; I
have changed the definition of DEFAULT_PATH in config.h from
'.${PATH_SEP}lib${PATH_SEP}' to '/usr/share/games/sangband/1.0.0'. The
version I got from compiling (with some source code tweaks) using
Makefile.std does pick up that path correctly, but the version obtained
by compiling with makefile.sdl does not. It also does not pick up my
redefinition of the "private user path" in the same file, but does if I
make the same redefinition in h-config.h; does the SDL port now ignore
config.h and use h-config.h instead, even though the latter does not
provide all of the same functionality (at least by default)?
Even if so, that still does not explain the fact that the same
executable does not run (that is, exits immediately with a return code
of 0, indicating no failure) even from its desired location, if its
filename does not end in '.exe'. The only mention of this string which I
find in the code is in main-sdl.c, and appears to be part of the code
which digs out the name of the directory from which the program was
run,j so I am not sure why this takes place.
A second issue is that the SDL port, even when run in its desired
location and with its desired filename extension, runs in fullscreen by
default and I see no mention of a way to switch that off. I prefer to
run windowed when running in a graphical environment, so that I can
easily make use of other windows for things like notes and calculations
(and even conveniently switch away to do other things, if necessary); if
I wanted to run fullscreen, I would do it from a console.
There is nothing inherently wrong with running in fullscreen, though
since it appears to be a change I don't think it should be automatically
made default, but there should definitely be a way to disable the
behaviour if the user does not want it.
There is also the minor issue that whenever I exit the program, I get:
==
*** glibc detected *** free(): invalid pointer: 0x0819bd00 ***
Aborted
==
Since this comes only on exit, it does not appear to affect actual use
of the program, but it is certainly not an intended or desirable thing.
Post by Leon MarrickIf things aren't so simple as that on your system, start by reading
the documentation in "makefile.sdl". I'm a Linux newbie so the docs
probably do need improvement.
One thing I have learned in even the comparatively limited time (several
years) I've spent following various open-source projects: the
documentation *always* needs improvement. Any exception is a momentary
aberration, which will inevitably be corrected by the inexorable pace of
development.
Post by Leon MarrickSo does the overall packaging. I want things to be as easy for Linux
folks as possible, with a true one-click install the eventual goal;
suggestions for achieving this are welcome.
One very useful step towards that goal - or the goal of a simple
install, at least, since "one-click" assumes a graphical interface which
does not really apply when compiling software under *nix - would be the
inclusion of a functional configure script (preferably *not* using
autotools, although that would be better than nothing), which performs
detection for libraries and so forth (and fails if they are not
available), and creates config.mak and config.h files with the
appropriate values for whatever system the script was run on. Such a
script would also accept arguments to specify desired locations for the
lib/ directories and for the private user path, whether or not to even
use private user paths, which port or ports should be compiled, and
(eventually down the line) anything else which can presently be
configured only by manually editing config.h and/or the appropriate
Makefile.
(Since you say you're a Linux newbie, a brief rundown of things which
you may in fact already know. The canonical installation method for
anything which is compiled from source is the simple sequence of:
<change to the directory where the souSince you sarce is>
./configure
make
<make sure that you are a user who has write access to the install
location set by the configure script>
make install
In practice it is frequently necessary to pass various options in the
./configure step, but in theory a basic probably-usable result should be
produced even with none at all.
It is reasonable to expect that anyone savvy enough to be attempting to
compile things under *nix is going to be familiar with this sequence. If
they are not, they will quickly become so as they look at various
projects.)
Another (and not directly related) step would be to have 'make install'
actually install the lib/ directories to the specified location, if they
are not already there or are out of date.
Closely related to that would be to come up with a saner default for the
location of those directories than assuming that the executable will
always be in the same location as the lib/ directory itself. This *may*
be a somewhat reasonable assumption under Windows, given its current
model of program installation, but it is not remotely reasonable under
*nix - or, I think, most other operating systems. As things stand, any
*nix user who does not want to either pollute directories in the PATH
with non-executable files or always specify the full relative path to
the sangband executable needs to edit config.h by hand.
I don't have a lot of free time for these purposes, but I would be not
unwilling to lend a hand in these veins - at the least testing and
advising, if not necessarily writing code myself.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
